Üres levelek
Issue #223
resolved
Üdv!
Segítséget szeretnék kérni az alábbi gonddal kapcsolatban:
Friss telepítés ( centos6 ) után, pár teszt levél van még csak a storeban, nem gond az elvesztésük.
Az érkezett levelek miután megjelennek a sima felhasználói keresések között, nem jelenítik meg a tartalmukat <nincs tárgy> szöveggel, és a .eml letöltése után 0 bájtosak.
Milyen beállítás hiányozhat?
Comments (17)
-
repo owner
-
repo owner
Ill. ha a logok alapjan ki tudnad deriteni, hogy milyen selinux szabalyok kellenenek, az nagy segitseg lenne.
-
Hello!
Köszönöm, az Issue #176 -ban találtak szerint -nálam fordítva-, amint az /usr/local/etc/piler.conf fájlban az encrypt_messages értékét állítottam be 1-ről 0-ra, a pilert újraindítva az onnantól érkezett levelek tartalma már megjelenik, illetve menthető és vissza is állítható a postafiókba.
A store tartalma (/var/piler/store/00) fájl szinten simán törölhető, és onnantól amik beérkeznek, már csak azok fognak látszódni a keresési listában is?
-
repo owner
Az encrypt_messages azt donti el, hogy a /var/piler/store/00 alatti file-ok tomorites utan titkositva legyenek-e? Rad bizom, hogy ezt mire allitod, de (es ez talan nincs kihangsulyozva) ennek az erteket azutan mar nem ajanlott modositani, mert akkor az archivum egyik resze titkositott, a masik meg nem, ami gondot okozhat a leveleknek az archivumbol valo elohivasukban.
A keresesi lista eredmenye nem a /var/piler/store/00 tartalma alapjan all elo, hanem a sphinx adatok (/var/piler/sphinx) alapjan. Igy ha csak siman torlod a store alol a file-okat, akkor fantom talalatok fognak megjelenni a gui-ban.
A.http://www.mailpiler.org/en/faq.html cimen le van irva a Q9-ben, hogyan lehet reset-elni (=mindent torolni belole) az archivumot.
-
Köszönöm.
Teljes törlést nem terveztem, csak amik nem kellenek; például: 1,2,3,7,8,11 stb. Kiválasztás után törölni esetleg weben keresztül. Ha nem lehet, akkor marad a Q9 reset.
-
repo owner
Lehet erre egy workaround-ot csinalni:
a piler adatbazisban a metadata tablaban allitsd a "retained" mezo erteket pl. 100-ra a torlendo uzeneteknel. Majd piler userkent futtasd le a pilerpurge parancsot.
-
Megtörtént a mező értékének állítása, majd a futtatásnál megállt:
sh-4.1$ pilerpurge
purge is not allowed by configuration, enable_purge=0
sh-4.1$
Hozzáadtam a piler.conf hoz az enable_purge=1 értéket, majd újraindítás után is a fentebbi hibaüzenetet kapom. Log:
Jan 1 21:25:42 piler pilerpurge[14557]: unknown key: "enable_purge"
Jan 1 21:25:54 piler piler[14542]: piler has been terminated
Jan 1 21:25:57 piler piler[14573]: unknown key: "enable_purge"
Jan 1 21:25:57 piler piler[14573]: reloaded config: /usr/local/etc/piler.conf
Jan 1 21:25:57 piler piler[14573]: piler 0.1.24-master-branch, build 836 starting
Megtaláltam a beállítást, az engedélyezése után viszon:
sh-4.1$ pilerpurge
Segmentation fault
sh-4.1$
-
repo owner
Ha az "option" tablaban megvan az enable_purge es 1-re van allitva az erteke, akkor probald ki, hogy upgrade-elsz az aktualis master branch-re (fent a Download linken megtalalod a linket), eleg csak a binarisokat megfrissiteni.
Ill. utana meg az adatbazis semat is frissiteni kell:
mysql -u piler -p piler < util/db-upgrade-0.1.24-vs-0.1.25.sql -
Köszönöm!
Adatbázis frissítése közben: ERROR 1071 (42000) at line 11: Specified key was too long; max key length is 3072 bytes
Újra futtatva: ERROR 1060 (42S21) at line 2: Duplicate column name 'ga_enabled'
-
A verziófrissítés után az sql hiba ellenére szépen elindult.
Jan 3 01:06:25 piler piler[5188]: reloaded config: /usr/local/etc/piler.conf
Jan 3 01:06:25 piler piler[5188]: piler 0.1.25-master-branch, build 856 starting
A purge is segfault nélkül visszatért.
sh-4.1$ pilerpurge
sh-4.1$
A crontabban szereplő scripteket megfuttattam, újra bejelentkeztem az useremmel, de a keresésben még mindig listázza a "0" vagy "100" -ra állított retained oszlopú leveleket. A deleted oszlop értékei 1 -re álltak ezeknél a leveleknél, de a keresésben még mindig szerepelnek. A logot már teleszórja hasonlókkal:
Jan 3 01:08:24 piler pilerget[5382]: /var/piler/store/00/76/7b/76/4000000052c425163a3abb0c00e8d4767b76.m: cannot open()
-
repo owner
OK, a torles utani elso indexeles utan (fel oran belul) tunik el a torolt level a kereses eredmenyei kozul.
-
21 órája futtatam a pilerpurget, még mindig listázza ezeket a leveleket is a kereső. A logba is ugyan úgy beleszórja a nem talált levelek megnyitásának próbálkozásait.
Jan 3 22:49:51 piler pilerget[11512]: /var/piler/store/00/76/7b/76/4000000052c425163a3abb0c00e8d4767b76.m: cannot open()
-
repo owner
Feltetelezem, az indexeles kozben mar tobbszor is lefutott,
A "grep main1 config*" parancs az alabbit adja vissza?
config.php:$config['SPHINX_MAIN_INDEX'] = 'main1,dailydelta1,delta1';
Ill. a sphinx semad a main - delta - delta-delta? Ha van a sphinx.conf-ban main1, dailydelta1 es delta1, akkor igen.
-
Az indexelés szépen fut, az újonan érkező leveleket szépen megjeleníti. A parancs az alábbi értéket adta vissza:
grep main1 config*
config.php:$config['SPHINX_MAIN_INDEX'] = 'dailydelta1,main1';
Ezek szerint ha átírom a fentire, akkor a kívánt eredményt kapom?
A sphinx.confban az alábbi sourcek és indexek kerültek bele a postinstall után:
source base source delta : base source main1 : base source main2 : base source main3 : base source main4 : base source dailydelta : base source tag : base source note : base index main1 index main2 index main3 index main4 index dailydelta1 index delta1 index tag1 index note1
Természetesen a többi paraméterrel együtt.
-
repo owner
Igen, probaljuk ki, hogy atirod a SPHINX_MAIN_INDEX erteket.
-
Köszönöm!
A fenti érték átírásával a kívánt hatást sikerült elérni, eltűntek a törölt levelek a keresés listából. Mivel a listában nem szerepelnek, már a logba sem kerülnek bele a törölt levelek megnyitásának próbálkozásai.
-
repo owner
- changed status to resolved
Akkor az ugy zarva.
- Log in to comment
Hello!
Probald meg kikapcsolni ki a selinux-ot.