Archive for the ‘FreeBSD’ Category

Greylist’ingo efektyvumas

Monday, February 26th, 2007

Manau, kad statistika kalba pati už save:

daily1.png

daily2.png
Pirmame grafike yra pastarosios paros gauti realūs laiškai, o antrame matosi kiek laiškų buvo atmesta. Rejected (tikriausiai beveik visais atvejais) reiškia, kad buvo paprašyta palaukt ir atsiųst vėliau.. Deja, vėliau negauta :) Taip pat dar matome, kad amavisd visgi randa kažkiek spam’o ir praeinančiuose laiškuose…

Kadangi laiškų srautas, kuris patenka amavis demonui, sumažėjo, tai galėjau sumažinti amavisd child’us iki vieno. Taip atsirado 120MB laisvo RAM’o :) O ir CPU daug MAŽIAU dabar apkraunamas.

Pasakykite spam’ui ate ate – greylisting :)

Friday, February 23rd, 2007

Apie šį metodą / technologiją filtruojant spam’ą jau senokai buvau girdėjęs bei išbandęs viename klientų pašto serveryje. Kažkaip niekaip neprisiruošdavau atnaujint dar poros serverių, kuriuose yra pašto dėžutės, kuriomis aš naudojuosi. Kadangi SPAMAS UŽKNISO JUODAI, tai praeitą vakarą ėmiau ir sutvarkiau greylisting’ą… Na, rezultatais kol kas esu labai patenkintas.. Kai seniau pro amavisd praeidavo daugybė spam’o, tai dabar jo neliko išvis (bent jau per ~ parą laiko negavau nei vieno laiško su spam’u, o seniau tas kiekis siekdavo 20-40).

Kas nežino, kas tai per technologija, tai trumpai paaiškinsiu: kai laiškas yra siunčiamas iš sistemai nežinomo IP adreso, tai tam siuntėjui yra pasakoma – “atleisk, bet dabar laiško nepriimsiu, bandyk po 15 (ar truputėli kitokio laiko tarpo) minučių”. Pašto serveriai tai puikiai suprantą ir laišką bando išsiųsti vėliau. Kai laiškas bandomas išsiųsti po 15 minučių ar vėliau, tai sistema laišką priima bei pašto serverio IP adresas įtraukiamas į žinomų ir patikimų pašto serverių sąrašą. Kitą kartą laiškas iš šio IP adreso priimamas be uždelsimo.

Tuo tarpu spamer’ių programos ir/ar virusai dažniausiai nesupranta tokio pašto serverio atsakymo, kad atsiųsk vėliau ir paprasčiausiai to laiško išsiųsti dar kartą nebebando.

Vienintelis minusas tik tas, kad laiškai ateina su uždelsimu. Bet viską kompensuoja švari pašto dėžutė :)

P.S. tekstas rašytas eiliniams interneto vartotojams (pagal adaptuotą programą), taigi techninių dalykų čia nelabai ir yra ;-)

P.S.2. O jeigu norėtumėte žinoti apie tai daugiau ir patys tai išbandyt, prašom:

postfix: warning: SASL authentication failure: cannot connect to Courier authdaemond: Permission denied

Monday, January 29th, 2007

Problema atsiranda po courier-authlib atnaujinimo. Sprendimas:

chmod o+x /var/run/authdaemond

Truputėli privertė pasikankinti :)

English version of this post

I’ve found that some English speaking visitors find this post useful.

Problem occurs after courier-authlib update. The solution is:

chmod o+x /var/run/authdaemond

It took some time to sort this out. Enjoy :)

FreeBSD laikas ir data

Thursday, January 25th, 2007

Tikriausiai daug kam tenka susidurti su tuo, kad kompiuterio laikrodis kartais daro šiokią tokią paklaidą.

Yra labai paprastas sprendimas – NTP (Network Time Protocol). Tiesiog įrašykite tai į root’o crontab’ą:

0 * * * * /usr/sbin/ntpdate europe.pool.ntp.org > /dev/null

Prisiminiau tai, nes eilinį kartą prireikė laiko korekcijos vienam serveriui.

PHP Fatal error: [Zend Optimizer] Zend Optimizer 3.2.0 is incompatible with eAccelerator

Monday, January 15th, 2007

Senokai naudoju eAccelerator ir esu labai patenkintas jo rezultatais.

Atėjo diena, kai vienam web’ui prireikė Zend Optimizer’io, nes jis užkoduotas su Zend Guard’u. Pagalvojau, kad jokių problemų neturėtų kilti – tiesiog sukišiu ZO ir viskas veiks (seniau yra tekę bandyti tai padaryti, deja, paaiškėjus, kad ZO tik viską labiau sulėtina teko atsisakyti ZO ir džiaugtis tik eA).

Taigi aš ramiai suinstaliuoju ZO iš FreeBSD port’ų ir pasileidžiu PHP CLI, kad pažiūrėčiau, ar viskas OK.. Va tada mano 3 minučių darbelis tapo geros valandos darbu:

PHP Fatal error: [Zend Optimizer] Zend Optimizer 3.2.0 is incompatible with eAccelerator

Pasirodo, naujoji ZO versija nebedraugauja su eA. Zend’o atstovai tai aiškina taip:

Zend Optimizer is not compatible with eAccelerator – both this extensions do operations on the PHP binary code and cannot co-exist.

Bet man tai atrodo keistai, nes seniau juk viskas veikė OK ir niekam niekas netrukdė. Greičiausiai tai kažkokios komercinės priežastys :)

Galimybės naudoti senesnę ZO versiją aš neturėjau, nes ji nepalaiko PHP 5.2, o ZO reikėjo tuoj pat, tad pradžiai tiesiog išmečiau eA. Vėliau nusprendžiau paeksperimentuoti su FastCGI ir pabandyti ZO naudoti tik tuose virtualiuosiuose serveriuose, kuriems yra ZO poreikis. Gan greitai tai pavyko :)

Truputėli paskaitinėjęs medžiagą internete perkompiliavau PHP su FastCGI palaikymu ir suinstaliavau mod_fcgid. Konfigūracija buvo gan paprasta.

Į bendrus serverio parametrus užteko įrašyt štai ką:

LoadModule fcgid_module libexec/apache22/mod_fcgid.so

<Directory /usr/hosting/new.autosara.com/www>
AddHandler fcgid-script .php
FCGIWrapper /usr/local/bin/php-fcgi .php
Options ExecCGI FollowSymLinks
allow from all
</Directory>

Taip pat teko sukurti /usr/local/bin/php-fcgi shell skriptą su tokiu turiniu:

#!/bin/sh
PHPRC=”/usr/local/etc/php/virtualusserveris”
export PHPRC
PHP_FCGI_CHILDREN=8
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS
exec /usr/local/bin/php-cgi

Iš esmės skriptas buvo reikalingas tam, kad be vargo būtų galima priskirti aplinkos kintamuosius su man reikalingais parametrais. Atkreipkite dėmesį į PHPRC, kuris nurodo, kur ieškoti php.ini failo.

Rezultatas buvo tas, kad konkrečiam virtualiam serveriui galėjau nurodyti jam skirtą php.ini failą. Taigi bendras php.ini krauna eA modulį, o kitame php.ini faile yra kraunamas ZO modulis.

Pentium 4 2.8 GHz vs. Core 2 Duo 6400 2.13 GHz

Friday, January 12th, 2007

Tai nėra kažkoks rimtas testas ar šiaip bandymas, bet šiaip asmeninis pastebėjimas apie realią situaciją.

Šiandien prireikė brute force’inti vieną MD5 hash’ą su mdcrack’ų. Greičio skirtumas buvo stebinantis, tad nusprendžiau apie tai parašyti :)

P4:
Collision(s) tested : 989092622 in 270 second(s), 788 millisec, 828 microsec.
Average of 3652634.7 hashes/sec.

Core 2 Duo:
Collision(s) tested : 989092622 in 99 second(s), 727 millisec, 317 microsec.
Average of 9917971.0 hashes/sec.

Be to, kiek žinau, tai mdcrack’as nemoka išnaudoti abiejų branduolių vienu metu :) Taigi viskas akivaizdu…

eAccelerator 0.9.5-RC1. Jis grįžo :)

Tuesday, August 1st, 2006

Seniau rašiau, kad teko išmesti eAccelerator’ių dėl pastebėtų negerų dalykų.

Pasirodžius Release Candidate 1 versijai nusprendžiau vėl jį išbandyti ir pažiūrėti, ar man ramybės nedavę bug’ai yra ištaisyti.

(more…)

Išmečiau eAccelerator’ių

Monday, July 3rd, 2006

Kiek seniau teko naudoti eAccelerator’ių, tai jis buvo tikras gėris. Bet, perėjus prie PHP 5.1.x išlindo bug’ai – eAcceleratorius vis crashin’a apache procesus. Žinoma, tai nebūtų labai baisi problema, jei crash’ų būtų vos keli per dieną, bet jie vyksta kas minutę, tad teko jį tiesiog išmesti. Teks laukti naujos versijos, kuri oficialiai palaikys PHP 5.1.x. Nors tikriausiai tada rinkoje jau bus PHP 5.2 :) Kiek žinau, tai sekanti versija ir bus būtent PHP 5.2.

Žinoma, būtų galima naudoti ir senesnę PHP versiją, bet mano projektams būtinai reikia minimum 5.1 versijos. Tikiuosi, kad neteks daryt atnaujinimų į 5.2 vien dėl išlindusių kritinių klaidų. Bet… Pastebėjau, kad PHP 5.1.4 apache modulis turi problemų su shared memory management’u ir neveikia normaliai kartu su tais moduliais, kurie irgi naudoja shared memory. Pamatysime. Gal visgi bus 5.1.5? Mažai tikėtina, nes CVS’e tokio branch’o jau neliko. P.S. su PHP 5.2 CVS’ine versija tos klaidos nepastebėjau.

FreeBSD versijos: kas, kur, kaip, kodėl?

Monday, March 6th, 2006

Internete dabar pilna darbinių stočių, kuriose naudojamos įvairios FreeBSD versijos: 4.x, 5.x, 6.x ir gal net senesnės. Kaip atsirinkti, ką naudoti?

FreeBSD kūrėjai rekomenduoja naudoti 6.0 versiją, nes, anot jų, ji jau yra pakankamai stabili ir ištestuota, taip pat yra daug atnaujinimų lyginant su 5.x ar 4.x seriją. Taip pat jie teigia, kad 4.x bus tuoj išvis nepalaikoma, o 5.5 (dabar yra 5.4) bus paskutinė 5.x serijos FreeBSD OS. Tad tai palieku spręsti Jums patiems, o aš renkuosi 6.x seriją. (more…)

FreeBSD atnaujinimas: 5.3-RELEASE į 6.1-PRERELEASE

Saturday, March 4th, 2006

Kaip jau rašiau prieš tai esančiame įrašę, tai teko išsinuomoti serverį užsienyje. Išsinuomotame serveryje buvo suinstaliuota FreeBSD 5.3-RELEASE, o aš norėjau naudoti 6.0 ar naujesnę. Todėl nusprendžiau sistemą atnaujinti cvsup metodu.

(more…)