Categories
Internet, Unix en security

Dovecot en verlopen berichten

Vroeger moest je met Courier en oudere versies van Dovecot nog handmatig mail verwijderen die was verlopen. Dit mede om oa Trash en Spam-folders te legen na een x-aantal dagen, maar zodra de mailstore begint te groeien begint dit steeds meer tijd te korten. Daarbij is niet elke implementatie van find even goed waardoor je alleen per 24 uur kan schonen. Maar met oa de komst van Dovecot 1.2 is de expire-plugin op orde en kan met een database backend wordt gekeken welke folders moeten worden geschoond.

De eerste aanpassing is om de configuratie file van Dovecot aan te passen met het volgende en Dovecot te herstarten.

protocol lda {
mail_plugins = expire ...
}
protocol imap {
mail_plugins = expire ...
}
dict {
expire = pgsql:/etc/dovecot/dovecot-dict-expire.conf
}
plugin {
expire = Trash 8 Trash/* 8 Junk 30
expire_dict = proxy::expire
}

Nu Dovecot weet wat de expire policy is voor oa de Junk-folder en de Trash-folder kan in een database wordt bijgehouden wanneer het volgende moment is dat er moet worden opgeruimd. Dit wordt gedaan wanneer er wijzigingen zijn aan de mailbox via de delivery agent of de imap-server. Als je lang genoeg wacht komt je vanzelf in de situatie dat de onderstaande test-commando’s aangeven en er daadwerkelijk kan worden opgeruimd.

$ sudo /usr/sbin/dovecot --exec-mail ext /usr/lib/dovecot/expire-tool.sh --test
Info: user1/Trash: stop, expire time in future: Tue Jan 26 17:15:48 2010
...
sleep
...
$ sudo /usr/sbin/dovecot --exec-mail ext /usr/lib/dovecot/expire-tool.sh --test
Info: user1/Trash: seq=1 uid=35624: Expunge
Info: user1/Trash: seq=2 uid=35625: Expunge
...
Info: user1/Trash: seq=89 uid=35721: Expunge
Info: user1/Trash: timestamp 1263658548 (Tue Jan 26 17:15:48 2010) ->; 1263671263 (Tue Jan 26 20:47:43 2010)
Info: user2/Trash: stop, expire time in future: Tue Jan 26 23:04:22 2010

Als je nu dit commando draait zonder de optie –test dan zullen de verlopen berichten daadwerkelijk worden verwijdert. Nu blijft de vraag hoe vaak je dit moet draaien en dit hangt af van belasting, maar ook hoeveel je kan bezuinigen aan schijfruimte of hoeveel zin het heeft om dit meer dan eens per dag te draaien.

Categories
Internet, Unix en security

Wat, waar en hoelang dingen te cachen

Door te cachen kan veel worden versnelt, maar tot welke prijs? Elke applicatie lijkt tegenwoordig zijn eigen cache-oplossing te hebben voor bv favicons, data binnen gehaald via HTTP, avatars, icons, maar ook sessies. En dit is natuurlijk allemaal leuk en aardig, maar als je regelmatig een backup wilt maken dan begint dit langzaam een probleem te worden. Een kleine scan in mijn homedirectory levert al z’n 1,6GB aan data op wat te bestempelen is als vluchtig.

$ du -sk .thumbnails .cache .gnome2/epiphany/favicon_cache .liferea_1.6/cache .evolution/cache .evolution/mail/{imap,nntp} .mozilla/*/*/Cache .nautilus/metafiles .purple/icons .config/gnome-session .config/session-state | sort -nr
983740 .cache
573764 .thumbnails
38088 .evolution/mail/nntp
30296 .evolution/mail/imap
3324 .gnome2/epiphany/favicon_cache
3284 .mozilla/firefox/h18d1d1h.default/Cache
1268 .nautilus/metafiles
428 .purple/icons
368 .evolution/cache
188 .liferea_1.6/cache
108 .config/gnome-session
100 .config/session-state

Nu zal het veel nut hebben, maar heeft het echt zin om thumbnails te bewaren van bestanden die al lang zijn gearchiveerd in /dev/null. En is het zinvol dat verschillende applicaties een eigen cache vullen om zo snel mogelijk een favicon op het scherm te toveren. Gelukkig volgen steeds meer applicaties de guidelines van Freedesktop.org om cache bestanden op te slaan in $HOME/.cache zodat ze makkelijk te excluden zijn voor oa backup en timemachine-achtige applicaties.

De vraag blijft dan eigenlijk over hoe lang een item in een cache moet blijven staan. Als het oorsponkelijk object niet meer bestaat? Als het al 30 dagen niet meer is geraadpleegd? Als de expiretime van bv het originele object is verlopen? Of laten we dit afhangen van de hoeveelheid vrije schrijfruimte of van de ondegelegen storage zoals een harddisk vs solid state disk. Een andere beslissing kan zijn dan lokaal cachen goedkoper is dan van ver ophalen. Bij dit laatste vraag ik me af of een HTTP HEAD-request echt veel extra kost.