Levelezoszerver adatbazissal v anelkul

Web, mail, IRC, IM, hálózatok

Szervusztok!

Jelenleg nem konkret segitseget kerek, csak otleteket

Gondoltam belevetem magam a levelezoszerverek vilagaba es telepitgetek hatha tanulok valamit. Talaltam egy leirast , amit jonak gondoltam es az alapjan elindultam. Majd kozben elgondolkodtam, hogy mivel ez a usereket csak fileban tarolna nezek hozza egy adatbazis alaput is. (Ok, meg valoszinuleg nem ertem az egeszet, de probalom, ez lenne a lenyege a projektnek). Szoval talaltam masik leirast adatbazis alapon. A dolog nem mukodik, szoval gondoltam mielott melyebben beleasom magam ujragondolom az egeszet.

Korulbelul mikor az alabbit olvastam az elso linken, akkor gondoltam h inkabb az adatbazist valasztom nem a sima file-ban tarolast.
As mentioned above, there's a wide range of password storage options, including a SQL database—in fact, storing passwords in a SQL database gives you the advantage of being able to offer users self-service password changes. However, because this is intended to be a single-user (or at most a very limited trusted few users) system, we're going to store our passwords encrypted in a flat file.

Most mariadb+postfix+dovecot+nginx van egyelore. Azt latom hogy az adatbazis mar most eleg sok memoriat zabal a tobbi alkalmzashoz kepest. persze alapjaraton

Kerdes:

  1. Mit erdemes hasznalni mondjuk 20 koruli felhasznalora napi 10 level/felhasznalo. Sima allomanyok v adatbazis. Errol nem talaltam hosszabb elemzest.
  2. Mik az elonyei ha database-t hasznalok sima allomanyok helyett.
  3. Mit konnyebb backupolni, koltoztenti ha kell, melyik hasznal tobb eroforrast, stb.
  • 7721 megtekintés

( Swifty v | 2015. 06. 14., v – 23:04 )

LDAP? Mármint user management....
Levél tárolásra meg inkább sok kicsi fájl :) Dovecot...
--
Debian Linux rulez... :D

( uid_17626 | 2015. 06. 15., h – 05:57 )

Nem lehet, hogy félre értettél valamit?
Csak a userek vannak db-ben és nem az /etc/passwd-ben. A levelek még mindig fájlban vannak az említett link mögötti módszernél.

( Zs | 2015. 06. 15., h – 16:02 )

Első lépésben a döntési szempontokat kéne tisztázni. 20 user annyira kicsi mennyiség, hogy ezért adatbázist teljesen felesleges telepíteni. Másfelől viszont ha tanulni akarsz, akkor vitán felül adatbázis, mert a nagybetűs Életben nem tipikus a 20 useres rendszer, a több ezres felhasználói adatbázist viszont nem illik plain/text file-ban tárolni.
Adatbázis tekintetében ismét két fő irány van: a különböző SQL rendszerek, illetve az LDAP. Az LDAP mellett az mindenképpen érv, hogy ha van AD, akkor célszerű azt használni, ebben az esetben viszont a levelező LDAP alapú kapcsolatot fog használni az user authentikációra.
A másik dolog, ami szempont lehet, hogy magát a levelet hol/hogyan tároljuk? Addig, amíg az user adat valamilyen adatbázisból jön, addig maga a levél már inkább különböző alkönyvtárakban, file-ként kerül tárolásra. (Az mbox a régebbi, ekkor egy "mappa" egyetlen file, de ebből törölni, karbantartani macera, tehát akkor inkább maildir, ekkor egy "mappa" egy könyvtár és a könyvtár file-jai a mappa levelei.) Ugyanakkor van olyan megoldás, amikor maguk a levelek is adatbázisba kerülnek - ez viszont méretéből adódóan SQL irány. Amiért ez egy szimpatikus irány lehet, az az, hogy külön táblába kerülhet a fejléc, külön táblába kerülhet a levéltörzs, a csatolmány. Ez meg ott kap szerepet, hogy amikor van egy böszme nagy csatolmány huszonöt címzettnek, akkor ebben a felállásban elég egy helyen tárolni a csatolmányt és a huszonöt helyről elegendő csak hivatkozni rá. Hozzá teszem, hogy egy olyan stuff, mint pl. a Zimbra, használ LDAP adatbázist is és MySQL adatbázist is - tehát nem annyira lehetetlen dolog, amiről mesélek.

Kosz, valami ilyesmire voltam kivancsi, kimerito valasz. LDAP nem lesz, szerintem most. Probakeppen haveri kornek egy listat akarok, szoval sok level sem lesz, de lehesznek csatolmanykent kepek, videok az biztos.

Kosz megegyszer, ilyesmi valaszokat vartam.

-+-+-+
Dropbox tarhely
Cave Canem
+-+-+-

( pirate | 2015. 06. 15., h – 16:46 )

kb. 20 user eseten:
- ha a mailbox-ok nem nagyok akkor lehet mailbox formatum, ellenkezo esetben maildir
- ha hasznalnak webmail-t (pl. roundcube) ami szinten kepes adatbazis hasznalatra, akkor adatbazis, innodb helyett myisam tablak, azoknak ugy tudom kisebb az eroforras igenye, migracional hasznos lesz az sql (pl. addressbook)
- LDAP tulzas ennyi embernek szerintem
- sqlite-ot keruld el

---
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

NYilván, de hősünknek lenne kb. 3 táblája max szumma 50 rekorddal, ami igen ritkán módosul. Szinte csak select-ek vannak, abból is alig. Erre szerintem megfelel a myisam is.

Bár én is innodb-t tettem a 2 user-es email server-em alá, szóval ezt visszaszívtam :)

Nem is cég, egy 5 dodós VPS, egyik haverral ketten használjuk. Na jó, a használjuk az túlzás, időnként elengedek rajta egy frissítést, ez a jelenlegi használat nagy része. Aztán persze vannak vele nagy terveim, de a megvalósítás, hát az még odébb van :)

Amúgy asszem innodb volt a default :)

Jelenleg 10+ valódi és nem tudom hány email maskkal már KKV szintet sem érem el, de nálam is sql-ből jönnek a user adatok. Maga a levelező csak SELECT-et csinál. Minden más évi pár alkalom pl.: kell egy új mask vagy kolléga csere volt vagy csak a jelszavát kell megváltoztatnom valakinek. Nem tudom mekkora cégnek kell lenni ahhoz, hogy a user_db csak tranzakció kezeléssel mehessen email accountok esetén, de attól tartok ekkora cég nincs hazánkban. Talán a legnagyobbaknál sem egy komplett osztály adminisztrálja ezeket reggeltől estig ami indokolná igényeidet. Szerintem annyira ritka feladat lehet ez nálunk, hogy abszolút elegendő erre a MySQL(MyISAM).

Pont nem a tranzakció ezek közül a legfontosabb. :)

A MyISAM észrevehetően gyakrabban lesz korrupt, mint az InnoDB, annyi plusz teljesítményt viszont nem ad a használata, hogy KKV-nál ne lehessen kibírni. Vagy bárhol máshol. A MySQL mindkét engine-t teljesen jól tudja kezelni, egy okot sem tudnék mondani, hogy miért inkább MyISAM, mint InnoDB.

Valóban, nem SELECT-nél. Egyáltalán nem is műveletfüggő, viszont egészen kis dolgok is megborítják néha a táblákat. Egy ismerősöm talált olyan bugot, hogy az RPi-jét valahányszor (szabályosan!) újraindítja, korruptak lesznek a táblák. Jó eséllyel persze vissza lehet őket hozni, de kinek hiányzik ez? :)

Ha már MySQL, akkor inkább InnoDB.

( jailhouse v | 2015. 06. 17., sze – 20:58 )

Ha nem akarsz szívni, akkor Office365

----------------------------
Előnevelt csirke kapható!