Categories
Internet, Unix en security

SpamAssassin verplaatsen

Soms moet je een databaseschema verplaatsen van de ene machine naar de andere. In veel gevallen is een export en import de meest slimme oplossingen, maar waar zou je het de applicatie niet laten doen. Zo ook met SpamAssassin waarbij alle voorzieningen in de applicatie zitten en wat wel zo veilig is als je dit op een draaiende omgeving wilt doen.

De eerste stap is om een data te exporteren en dan te verplaatsen naar de juiste machine:

$ sa-learn --backup > sa-learn.dump

Op de nieuwe machine is het lege schema al geladen en kan een import worden gedaan:

$ sa-learn --restore sa-learn.dump
$ sa-learn --force-expire

Als laatste stap wordt ook door SpamAssassin gekeken of en wanneer er een expire moet plaats vinden. Dit zorgt ervoor dat als je auto-expire aan hebt staan je database niet bij de eerste e-mail al direct wordt gecontroleerd. De kans op vertraging wordt hiermee beperkt en het is duidelijk dat SpamAssassin met de nieuwe dataset goed kan werken.

Categories
Internet, Unix en security

Bayesian-filtering en (bijna) geen backups

Elk bestand en database moet op tape worden gezet is het motto bij veel sysadmins, maar is dat wel zo. En in veel gevallen hebben ze gelijk, maar helaas niet als het een database betreft die wordt gebruikt voor Bayesian-filtering. Maar waarom maak je backups? Om data die waarde heeft veilig te stellen is eigenlijk de stelregel.

Maar wat maakt Bayesian-filtering nu zo anders? Laten we eens kijken op een testnode.

$ sudo sa-learn --dump magic
0.000 0 3 0 non-token data: bayes db version
0.000 0 25556 0 non-token data: nspam
0.000 0 11331 0 non-token data: nham
0.000 0 204764 0 non-token data: ntokens
0.000 0 1262669327 0 non-token data: oldest atime
0.000 0 1263329413 0 non-token data: newest atime
0.000 0 0 0 non-token data: last journal sync atime
0.000 0 1263273928 0 non-token data: last expiry atime
0.000 0 345600 0 non-token data: last expire atime delta
0.000 0 21267 0 non-token data: last expire reduction count

Wat we zien is dat de database is gevuld met z’n dikke 25000 spamberichten en 11000 hamberichten, maar ook dat de database ruim 204000 kenmerken bevat om zijn berekeningen op laten plaats vinden. Twee leuke kenmerken van dit overzicht zijn dat er een data in de journal zit omdat dit direct in echte database zit ipv in de standaard BerkelyDB en de tweede is de hoeveelheid tokens. In een standaard database zitten maximaal 150000 tokens en welke bij een expire automatisch worden opgeschoond naar 75% van die 150000 tokens. Deze installatie heeft auto-expire uitstaan waardoor dit extern moet worden geregeld, maar ook dat de database meer dan een normaal aantal tokens mag bevatten.

Maar wat heeft dit met backups te maken? Waarom zou je data in veiligheid brengen als er elke uur een nieuwe tokens worden toegevoegd en elke dag een expire wordt gedaan? Een constante stroom aan nieuwe data zorgt ervoor dat de database altijd in flux is zoals het hoort en in het slechtste geval is je database een paar uur aan het bijleren. Om dit laatste te overkomen zou je spam- en hamberichten bijvoorbeeld in de Trash-folder van de IMAP-server kunnen laten staan die na een paar dagen deze automatisch verwijdert uit standaard policy. Het verplaatsen van alle berichten van de Trash-folder naar de INBOX en bij de volgende ronde komt alles weer vanzelf in de database. Deze methode werkt ook vrij goed als de layout van de database wordt aanpast bij een upgrade en de database moet opnieuw worden opgebouwd.

De vraag die sysadmins misschien wat meer moeten vragen of de data echt naar tape moet, want we leven steeds meer in een tijdperk dat backups onmogelijk(er) beginnen te worden. Er zullen dus andere oplossingen moeten worden gezocht om data veilig te houden voor gebruikers. De eerste stap is het niet op tape zetten van data die je kan reproduceren.

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.