Aktualizace návodu na mailserver - sbírám požadavky (diskuse)

[Honza Balák]

Já bych byl pro uživatele v MySQL

[Zdeněk Burda]

A důvod?

MySQL:

• + pro některé lidi srouzmitelnější, když už někdo zná LDAP tak je téměč 100% jistota, že si poradí i s MySQL
• - při nasazení do stávající infrastruktury se docela složitě řešit spolupráce se stávajícími systémy, v případě LDAPu je to snadnější

LDAP:

• + snadno použitelné ve spolupráci s Active Directory
• + snadné využití jedné databáze identit (LDAPu) pro velké množství různých aplikací na síti

[Honza Balák]

Asi bych argumentoval tou srozumitelnosti...

[jm]

A důvod?

MySQL:

• - při nasazení do stávající infrastruktury se docela složitě řešit spolupráce se stávajícími systémy, v případě LDAPu je to snadnější

Tezkej nesouhlas. MySQL neni pro tyhle ucely problem pouzivat zcela oddelene od dalsiho fungovani systemu jen pro zvolene sluzby (SMTP/IMAP/POP3, FTP, zaheslovane weby v Apachi, uzivatelska nastaveni spamassassinu atd. atd.), zatimco jakmile pridam ldap do /etc/nsswitch.conf, tak se rozesere kde co.

(P.S. Ne, nijak nezastiram, ze tahle opensource podoba active directory mi opravdu, ale opravdu k srdci neprirostla).

[Zdeněk Burda]

Stejně jako necpeš do nsswitch MySQL, tak tam nemusíš cpát LDAP. Všechny způsoby využití MySQL, které jsi napsal, můžeš realizovat i s LDAPem.

Docela dost SW se umí proti LDAPu ověřovat a tahat si z něj uživatele, ale z MySQL to umí až po tom co se mu trochu (víc) pomůže.

[jm]

Docela dost SW se umí proti LDAPu ověřovat a tahat si z něj uživatele, ale z MySQL to umí až po tom co se mu trochu (víc) pomůže.

Mel jsem za to, ze rec je o mailserveru, pripadne o nejakem webhostingu. Tak presne nevim, o kterem SW je rec, postfix/courier-imap/pureftpd/apache/spamassassin a dalsi tohle umi bez problemu.

Me je to koneckoncu jedno, openldap mi proste na server nepachne, presvedcovani je zbytecne. Mam s tou veci katastrofalni zkusenosti; ale at si kazdy pouziva, co chce. :P

[CET]

Muzes mi napsat, jak udelas autentizaci uzivatelu s MySQL tak, aby ti externi aplikace nepozadovala cteni hesel? Ja vim, hesla jsou jenom hash, ale i tak se daji generovat slovniky s heslama v hasi a pak je nalezeni hesla otazka vterin.

V LDAP jsou ulozeny i hesla, ale LDAP lze nastavit tak, ze pole heslo se neda anonymne cist, pouze admin a uzivatele pouze vlastni hesla. Navic prihlasovani je reseno pomoci BIND (pripojeni), takze se z LDAPu zadny heslo nemusi dostat ven. Jde tohle udelat v MySQL? Predstavuju si to tak, ze do "NEJAKE" tabulky pridam uzivatele a od te chvile se bude do mysql tento uzivatel prihlasit. Vim, ze pro mysql existuje tabulka mysql.user, ve ktere jsou uzivatelske ucty, ale to je primarne pro administrativni pristup do DB.

A tohle je IMO nejvetsi vyhoda LDAP autentizace.

Me je to koneckoncu jedno, openldap mi proste na server nepachne, presvedcovani je zbytecne. Mam s tou veci katastrofalni zkusenosti; ale at si kazdy pouziva, co chce. :P

Zajimalo by me, co se ti s openldap stalo. Podle prvniho prizpevku to vypada, ze si rozhasil nsswitch a pak ses nemohl do systemu vubec prihlasit. Ale jak spravne pises, zakladni system vubec na LDAP predelavat nemusis, staci predelat jenom sluzby (postfix, courier atd).

[jm]

Zajimalo by me, co se ti s openldap stalo. Podle prvniho prizpevku to vypada, ze si rozhasil nsswitch a pak ses nemohl do systemu vubec prihlasit. Ale jak spravne pises, zakladni system vubec na LDAP predelavat nemusis, staci predelat jenom sluzby (postfix, courier atd).

Co se mi stalo krom toho, ze ten krap zpusobil, ze server kvuli nekolika udev pravidlum ve spojeni s chown 0:0 bootoval cca hodinu, protoze LDAP jaksi neni schopen pochopit, ze kdyz neco nemuze najit, tak se na to ma v rozumne dobe vysrat (rozumna doba != defaultne cca 4 minuty na jedno vyhledani) a pouzit fallback?

Nebo krom toho, jak se ze spravce balicku stala zcela nepouzitelna vec kvuli dodnes nevyresenu bugu? No, jinak uz nic, pak uz jsem totiz tu vec smazal, nikdy vic nenainstaloval a ani to delat nehodlam. Tohle opravdu nemam zapotrebi.

[Mr.Yoda]

mysql :-*

[pavlix]

A co takhle nějaký plnohodnotný databázový stroj?

[Jakub Suchy]

MySQL v tomhle pripade slouzi jako obycejny storage. insert, select where...

Kdyz pominu hloupe vykriky o tom, ze MySQL je neplnohodnotny databazovy stroj, pouziti jine databaze by bylo jako s kanonem na vrabce.

[pavlix]

Když jsem mysql přestal používat ve vlastních projektech, tak měla ještě problémy s kódováním znaků a tuším, že se jí nechtělo to transakcí. A taky myslím neuměla přihlašování bez hesla (přes přihlášeného uživatele).

Když nad tím pak člověk chce postavit nějaký další systém, je to podle mě škoda.

[Oto Petřík]

Přivítal bych návod s LDAP - bylo by pěkné mít jen jednu databázi.

[DjAARA]

Co se týče mě, tak bych také preferoval variantu s LDAPem už jen kvůli možnosti sdílet informace mezi různými službami.

[Johny z Podoli]

Mysql je opravdu srozumitelnější. Pokud pujde nakonec o LDAP (což uvítám) tak bych prosil opravdu step by step věci ldapu se týkající. Nerad bych zatuhl na mojí neschopnosti práce s LDAPem..

[Dalibor Smolík]

Moc se těším na hezký návod. To, co jsem popsal já je funkční a použitelné, ale jen pro velmi malou firmu nebo pro domácnost - určitě bych vyzkoušel něco dokonalejšího.

[David Jaša]

Přidávám se k LDAPu s prosbou kapitolku, kde bude popsáno rozchození LDAPu v síti LDAPem netknuté.

[trekker.dk]

Taky tak.

[Bernie]

+1

[pavlix]

Kontroly správnosti SMTP komunikace příchozích zpráv, DNS odesílajících mailserverů, greylisting....

[hugis]

Tak na toto sa fakt teším. Mám pocit, že na mojom servery to už je celkom dobre rozbité a rád si to dám do poriadku. Je mi úplne jedno či LDAP (poteší kapitolka o rozchodení LDAP) alebo MySQL, len prosím čo naskôr. Ďakujem.

[ajtak]

Proc chces cpat uzivatele do DB? Proc nenechas jen unix uzivatele?

Proc to delat jednoduse, kdyz to jde slozite, ze?

[jm]

Proc chces cpat uzivatele do DB? Proc nenechas jen unix uzivatele?

Proc to delat jednoduse, kdyz to jde slozite, ze?

Neni nad nazor odbornika, ze... Samozrejme protoze kazdy emailovy ucet vcetne aliasu a domenovych kosu je idealni resit uctem v systemu, nejlepe vcetne pristupu k shellu. Ty jses ale mudrc.

[tezkatlipoka]

zrovna pritup k shellu neni argument pro nic, systemovej uzivatel /v nasem pripade pouzitej pro postu/ vubec shell nepotrebuje. Rozumim ti, ale zrovna shell neni vubec zadnej argument.

[Zdeněk Burda]

tak lepší argument: snadná správa velkého počtu uživatelů a domén (velký=stovky, tisíce, desítky tisíc), možnost delegace některých činností správce na "pouze poučené" uživatele, snadno proveditelné hromadné změny, snadný export/import uživatelů

[ajtak]

tak lepší argument: snadná správa velkého počtu uživatelů a domén (velký=stovky, tisíce, desítky tisíc)

Tohle jsi mel uvest hned v clanku, ze budes delat "velky" mailserver a ne pro pet a pul lidi...

BTW: O co slozitejsi je sprava systemovych uzivatelu oproti sprave uzivatelu v DB?

[jm]

BTW: O co slozitejsi je sprava systemovych uzivatelu oproti sprave uzivatelu v DB?

Ja teda nevim, uz jsi videl nejaky webhosting, ktery resi spravu emailovych uctu tak, ze se nejaka PHP nebo jina aplikace vrta v systemovych uctech? Ja ze bych se mu rad vyhnul. :P

[pavlix]

Těžko říct, ale třeba LDAP se běžně používá na obojí (systémové účty i mail). Vlastně sám budu brzo něco takového řešit... uvažuju ale nejspíš o PostgreSQL

Ale v článku jsem nic o webhostingu psaného neviděl.

[frEon]

myslim, ze je jasny, kdyz premejsli, jestli nacpe uzivatele do mysql nebo ldapu, ze to pro par uziuvatelu nebude.

[pavlix]

Přeložím do češtiny: "O co složitější je správa uživatelů v jednom typu databáze (/etc/passwd) než v jinym (SQL tabulka)."

je to dost podobné, akorát spousta lidí je zvyklá na SQL, navíc si volíš sloupce podle sebe. Líp se upravuje za běhu (/etc/passwd se musí celé přepsat najednou, pokud něco měníš), rychlost apod.

Navíc /etc/passwd používají automaticky i aplikace, které nechceš, takže možná trochu i bezpečnost (záleží na konkrétním případu).

[Zdeněk Burda]

Protože píšu o mailserveru, nikoliv o shell serveru

[al-Quaknaa]

Já bych měl jen poznámku k softwaru - asi to budeš chtít zase stavět na Courier platformě, ale četl jsem poměrně dost chvály na Dovecot, tak moc tomu nerozumím, ale kdyby ti taky přišel lepší, tak ho můežš zahrnout ;) Druhá věco je to, že by se mi líbilo, kdybys popsal, jak zprovoznit antispam se systémem dspam a to tak, aby se dspam trénoval pomocí spamassassinu + uživatele, který spam, co mu dojde do inboxu označí jako spam (positive negative se tomu tuším říká) a skutečné maily zařazené do spamu (false positive) přehodí do inboxu. Na stránkách dspamu je to poněkud komplikovaně popsané, myslím, že by to bylo docela hezké. Ještě bys mohl zařadit greylisting anti-spam proxy, já používám hermes, konfigurace byla velice jednoduchá, takže to moc námahy nebude a chytí to vážně asi těch 90% spamu :) Nakonec se omlouvám, pokud plácám blbosti, mailserver provozuju malý a výhradně podle různých návodů, nejsem expert jako ty :)

al-Quaknaa

[Zdeněk Burda]

Bude to dovecot, používám ho poslední dobou skoro všude. Courier jsem měl před těmi pár lety docela prověřený, což se o dovecotu nedalo říct. Která varianta antispamu bude popsána ještě zvážím. Greylisting bude určitě (sice ne hermes, ale to je asi jedno). Expert také nejsem, jen to prostě dělám

[al-Quaknaa]

No, určitě jsi větší expert než já :D A to právě proto, že to děláš ... ve větším měřítku, než já. Dovecot - super :) Greylisting - můžu se zeptat, co teda používáš? rád se přiučím... Antispamové řešení - já teď používám hermes+spamassassin a funguje to dobře, ale když jsem viděl, kolik zátěže navíc to dělalo, než jsem tam ten greylisting dal, a tedy kolik zátěže by to dělalo i s greylistingem, když by tam pak byl jen náročný spamassassin, tak jsem si říkal, že další vrstva by se hodila. Ale třeba je to blbost a zbytečně náročné ...

[Marv-CZ]

Mohl bys tam zahrnout i doručování přes LMTP (pokud to Courier umí, já používám Cyrus). Je to užitečné ve firemních sítích, kdy postifix sedí na gateway a pošta se ukládá na server uvnitř sítě. Když jsem to poprvé konfiguroval, tak jsem zjistil, že užitečných informací o tomto je na netu celkem málo.

[CET]

Koukal jsem na ten aktualni manual. Vynechal bych PAM - udelal bych to ciste nativne. Pro LDAP saslauth funguje primo, ostatni sluzby taky, pokud pouzivaji saslauth, nebo maji vlastni modul. Ale sel bych urcite do LDAPu.

[Zdeněk Burda]

Zatím to vypadá tedy na LDAP, saslauthd nepoužívám - postačí dovecot, když už tam běží...

[Zdeněk Burda]

Tím taky padá PAM, nemusí se nijak řešit.

[Max]

LDAP, ověřování přístupu k smtp pomocí účtu a hesla z LDAPu ...
Zdar Max

[fabian]

Super zprava, ze budes psat aktualizovany navod. Tesim se na nej:). Byl bych radsi, kdyby bylo pouzito MySQL.

[mlz]

A nešlo by LDAP řešení a současně SQL řešení (bez ohledu na MySQL, PosgreSQL, MSSQL...:)

Prostě uživatelé LDAPu/SQL přskočí následující kapitolu

[Zdeněk Burda]

Přemýšlel jsem o tom, že bych udělal LDAP a MySQL najednou, ale je to sakra hodně práce, protože konfigurace všeho se kompletně liší.

Použít MSSQL je zbytečné - žádný z použitého SW s tou db neumí nativně komunikovat.

PostgreSQL - tu databázi mám rád, ale mailserver jsem proti s ní nestavěl.

[rincewind]

Priklanel bych se take k verzi jak s LDAPem, tak s MySQL. Vim, ze je to dvoji prace, ale dalo by se to tedy aspon nejak oznacit (tahle cast je obecna / tahle cast je konkretne pro LDAP)?

[David Jaša]

Ano, naznačit, co je obecné a co je specifické pro dané řešení (s případným odkazem) by bylo fajn.

[bluemoon]

vzdyt se toho moc nezmenilo, struktura databaze muze byt stejna, pristupove soubory do databaze pro postfix jsou take stejne. Jedine, co se zmenilo je pouzivani maildropu, ktere migrovalo ke courieru a ten si pristupuje do databaze pres pam viz postfix+mysql+courier