Cât timp pierzi zilnic ștergând spam?

Probabil prea mult. Și, chiar dacă ai un filtru antispam activat în MTA (dublat, de ce nu, de filtrele clientului de mail), spammerii sunt din ce în ce mai inventivi în a trece de ele.

În ultimele zile a fost foarte activă o campanie spam de tipul stock pump-and-dump pentru o companie cu indicativul de bursă RCHA. Ce a făcut-o să iasă în evidență este transmiterea mesajului sub forma unei imagini GIF cu diverse variații de conținut, restul textului din email fiind pasaje de text aleatoare cu menirea de a scădea scorul de spam acordat de filtre.


Citește restul articolului…

Monitorizarea unei aplicații PHP business-critical

Dacă ai o platformă PHP business-critical, e foarte sănătos să știi imediat ce are o problemă. Cu toate unit testele sau QA-ul intern, erori se pot strecura și, până îți semnalizează un client problema, pot trece ore sau zile bune, timp în care pierzi potențiale conversii.

O aplicație PHP care rulează pe un sistem *nix poate fi monitorizată foarte ușor cu ajutorul pachetului logwatch, preinstalat pe majoritatea distribuțiilor Linux enterprise. Mai jos vom face referire la configurarea acestuia pe un server ce rulează CentOS 6, cu PHP rulând prin Apache mod_php, prin FPM (Apache, nginx, lighttpd etc) cât și direct din CLI.

logwatch, după cum se poate deduce din numele său, monitorizează jurnale și trimite notificări în momentul în care în ele apar secvențe text definite de tine. În cazul nostru, vom configura jurnalizarea PHP, apoi șabloanele de monitorizare ale logwatch și în final execuția automată a logwatch.
Citește restul articolului…

Ai jurnale?

Foarte mulți administratori de servere sau site-uri nu acordă suficientă atenție jurnalelor. Bineînțeles, majoritatea își dau seama de acest lucru tocmai când s-a întâmplat buclucul și au cea mai mare nevoie de ele. Jurnalele te pot ajuta, așa cum am făcut și noi pentru un client acum ceva vreme, chiar să strângi dovezile necesare autorităților în cazul unei intruziuni într-un server și furtului de date.

Pe lângă activarea opțiunilor de jurnalizare cât mai detaliată în servicii, e necesar să te asiguri și că jurnalele conțin tot ce primesc. Dacă un serviciu Linux generează foarte multe mesaje pentru jurnalizare, e posibil să vedeți prin /var/log/messages intrări de genul:

Feb 5 17:34:29 rsyslogd-2177: imuxsock begins to drop messages from pid 18617 due to rate-limiting
Feb 5 17:34:31 rsyslogd-2177: imuxsock lost 104 messages from pid 18617 due to rate-limiting

Citește restul articolului…

Cu email-urile la doctor

Cu o săptămână în urmă am ajuns la concluzia că One Pixel are nevoie de un server nou. Sistemul inițial era un sistem Intel OEM, cu SSD-uri în RAID, procesor quad-code și alte bunătăți, dar cu un mare neajuns – 4 GB RAM. Cum bazele de date deja o depășeau cu mult ca mărime pe disc, caching-ul ajunsese să fie foarte ineficient și o mare parte din citiri trebuiau să se facă direct de pe matricea RAID, mult mai înceată decât RAM-ul. Ce-i drept, placa de bază suporta 8GB RAM tip DDR2 în format 2×4, dar care nu se mai găsește deloc pe piața IT de la noi.

Noul server a fost de această data construit de noi, însă tot pe o platformă Intel. Am ales un weekend în care să putem opri serviciile, să facem migrarea datelor și configurarea și am purces la treaba. De la CentOS 5 am trecut la CentOS 6, sistemul de fișiere de la ext3 la ext4, MySQL 5.5 vanilla a devenit 5.6 cu foarte multe patch-uri, PHP 5.3 înlocuit cu PHP 5.4. În final am reconfigurat restul de servicii și am repornit MTA-ul.
Citește restul articolului…