Tisztelt fórumtársaim.
Annyit szeretnék,hogy van egy adott szerver (Linux Debian).
Quota bevan állítva a particióra, mindenkinek létrevan hozva a maximális kvótája(soft és a hard kvóta).
A tárhelynél ez tökéletes is.
Levelezés most vmail felhasználóként van tárolva,vmail:vmail tulajdonossal. Virtualba mennek a levelezések Mysql-el.
Amit szeretnék: a levelek is legyenek azonos felhasználóként mint a tárhely. Ha átállítom,akkor nem tud bele írni(ez megérthető miért).
Ez a kisebbik bajom.
Adatbázissal mi a helyzet? Ugyebár az adatbázis táblák fájlai mysql-ként vannak ott. Ennél betudnám-e állítani a quotát azonos felhasználóra?
Ha azonos felhasználóba vannak a fájlok, számolja a méretét,és ha eléri a hard kvótát megáll az írás,nem engedi.
Jelenleg van egy script ami hozzászámolja a levelek méreteit a tárhelyhez, és az adatbázist is. és elveszi a jogosultságot,de jobban örülnék az elöbbi megoldásnak.
Van valami ötletetek?
Hozzászólások
(Legközelebb légyszi próbálj meg eljutni a Debian-ig a topikválasztásban. Köszi.)
--
trey @ gépház
mmint a Debianig.
t
mármint
--
joco voltam szevasz
lájk! :D
Rendben, így hirtelen nem találtam. Bocsi.
Nemtom a 6-os mysql-ben van-e tablespace quota, nem néztem, de az alatti verziókban igen szopó.
Tipp table fájlok groupja legyen az user groupja (amin groupquota van).
Valami ilyesmi megoldásra gondolsz?
Hogy ezt a MySQL szeretni fogja-e így nem tudom.
♲♻♲
próbáltam persze,de permission denied-el visszadob.
MySQL adatbazis fajlok jogaival jatszani veszelyes, plusz felesleges. Nincs 1:1 megfeleltethetoseg a tarolt adatok es az adatbazis fajlmerete kozt. Tessek scripttel monitorozni (tablameretet le lehet kerdezni), problema eseten levelezni, a hard meg legyen az account suspendje (a vhost letiltasa).
A levelezesre mit hasznalsz? Konfigokat, reszleteket legyszi. Van erre megoldas, de tudni kene, hogy honnet indulunk.
--
Nagyon szépen köszönöm a válaszodat!
Gondolom ez elég lesz:
levelezésre: postfix
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
és úgy épül fel,hogy
/home/vmail/[domain]/[fiok]/(cur|new|tmp)
Az adatbázisnak mélyebben utánanéztem,ahogy látom,ha megakadályozom,hogy írjon leállhat az egész mysql adatbázis is, szóval marad a monitorozás.
UPDATE: Így elnézve a virtual_uid_maps,éa gid a "bűnős". Keresek hozzá mysql proxy-t.
Köszönöm a válaszodat!
Alapvetoen nem jo otlet a MySQL kvotat egy kalap ala venni a filerendszer kvotaval, tobb okbol sem:
A fentiek miatt en azt javasolnam, hogy mindenkeppen ugy alakitsd ki a dijcsomagjaidat, hogy a MySQL tarhely kulon tetelkent legyen feltuntetve. A kvotazashoz pedig hasznalhatsz MySQL Quota Daemont
Mondjuk mi nemes egyszeruseggel unlimited MySQL kvotat adunk, es csak monitorozzuk. Ha valaki nagyon elszabadul, azzal beszelunk, hogy ezt igy nem kellene, de egyebkent igazabol nem erdekes, a rendszer birja :-)
--
Akár ez is megoldás. A felhasználó szemszögéből valószínűleg az a legjobb megoldás, ha van valami névleges kvóta mind az adatbázison, mint a tárhelyen, ha azt túllépi, akkor szól neki a rendszer, hogy ejnyebejnye. Ha tartósan vagy nagyon túllépi, akkor meg korlátozza a szolgáltatást.
En a mysql total foglalasat nezem. Ha hirtelen nagyon megugrik, akkor van script, ami legyujti a db mereteket, es igy latom, hogy ki szallt el nagyon. Az esetek 90%-aban ez vagy valamilyen feltoresre utal, vagy pedig alkalmazashibara, tehat egyebkent is jo, ha tudok rola.
Felhasznaloi oldalrol eddig sosem volt igeny arra, hogy legyen valami hatar.
--
Arra ne várj, hogy a felhasználói oldal bármilyen határt fog követelni magának. Minden legyen korlátan, végtelen és persze ingyen, de minimum harmadáron szerintük.
--
Apache Solr Druplahoz és Wordpresshez: http://solr.vpspro.hu
Levelezés most vmail felhasználóként van tárolva,vmail:vmail tulajdonossal. Virtualba mennek a levelezések Mysql-el.
Amit szeretnék: a levelek is legyenek azonos felhasználóként mint a tárhely. Ha átállítom,akkor nem tud bele írni(ez megérthető miért).
Ez a kisebbik bajom.
es ezt most igy hogy? A virtual userek meg a unix id alapu kvota egy kicsit uti egymast. De pl. a dovecot-hoz van maildir quota vagy valami ilyesmi, igy ha a local delivery-be bevonod a dovecot-ot, akkor azt szepen le tudja kezelni a .maildirsize (vagy valami ilyesmi) file alapjan...
Jelenleg van egy script ami hozzászámolja a levelek méreteit a tárhelyhez, és az adatbázist is. és elveszi a jogosultságot,
jo az. Mondjuk az nem vilagos miert is jo, ha a mail tarfoglalast osszevonod a mysql-lel...
Miert kell nekem sajnalnom a Klubradiot?
"A virtual userek meg a unix id alapu kvota egy kicsit uti egymast."
Miert is? Mert unix id-t nem lehet adatbazis alapon generalni?
nss-mysql -lel a problema siman athidalhato, annyi trukk van, hogy a mailbox id-jehez kell egy konstans eltolast adni, hogy az elso ezer mailbox ne irja felul a rendszer userek id-jet, de ennyi.
"De pl. a dovecot-hoz van maildir quota vagy valami ilyesmi"
Ez per-mailbox kvota. O az OSSZES mailbox tarhelyet akarja korlatozni.
--
hát akkor az ÖSSZESRE tesz kvótát :D
Nem erted. A .maildirsize az per-mailbox van ertelmezve, mindig. O viszont azt szeretne, hogy az egy accounthoz tartozo osszes mailboxnak egyben legyen egy darab kvotaja. Tehat, leforditva: az ugyfel levelezese minden hozza tartozo mailboxot figyelembe veve sem haladhatja meg a kvotat.
--
A levelezésre megoldás:
http://wiki2.dovecot.org/VirtualUsers + http://wiki2.dovecot.org/LMTP
A Postfix-nek a maildir-ben található levelekhez soha egy kisujjal sem kell hozzányúlnia,
a Dovecot meg tud megfelelő UID-al futni ha egy adott maildir-hez hozzáfér...
♲♻♲