От около 2 седмици php 5.3 влиза във историята бавно но сигурно. На 11-ти обявиха края на поддръжката му и че ще бъдат пускани само кръпки по сигурността в продължение на 1 Roku. В общи линии PHP 5.4 преминава в стадии old stable а PHP 5.5 става stable, което е малко забавно понеже все още част от допълненията и плъгините на php не работят съвсем коректно но пък и версия 5.5 е доста нова затова ще се въздържа от миграция към нея.

Та нека да си кажа за миграцията ми към 5.4 от 5.3. Предварително бях пуснал информация за остарелите функции, такива които са променени кардинално и такива които вече няма да се поддържат за да нямаме драми и от двете страни дали ще запали или не 😉 Та днес сутринта избрах час за старт на миграцията около 7 като стана, че да има минимални болки при миграцията ако не мине гладко. За моя огромна изненада всичко мина повече от гладкокомпилирах си PHP 5.4.17 стартирах apache-то и о небеса всичко е там. Бърз поглед из логовете няма рев на depricated или въобще непознати функцииявно момчетата са си свършили работата добре. След това ми остана само да прекомпилирам и допълненията които са компилира със старото API като APC, RAR и прочие. Втори рестарт и всичко заспа. Отделно очаквам подобрения в производителността тъй като навсякъде хората сочат с големия пръст едни таблички дето се показва как PHP 5.4 консумира по малко РАМ и изпълнява скриптовете по бързо.

Преди няколко дни излезе Xampp 1.8.0 вчера след надграждане от версия 1.7.7 имах доста интересен проблем. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403

Access forbidden!


New XAMPP security concept:

Access to the requested object is only available from the local network.

This setting can be configured in the filehttpd-xampp.conf”.

Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. Wtf ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Require all granted. О да еврика. Това е новия контролен механизъм който влезе в apache 2.4.x. С него се дава достъп или се отказва такъв на всички изискани, в общи линии се имитира Allow/Deny функционалността :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. След промените при мен изглежда така

<Directory “/opt/lampp/phpmyadmin”>
AllowOverride AuthConfig Limit
Order allow,deny
Allow from all
Require all granted
</Directory>

 

Вианги може да се пробва и друга дивоти, например да се преименува папката phpmyadmin на нещо други и да се направи alias към не. Но е по грозно и не особено смислено 🙂

p.s Питаха ме защо ползвам XAMPP а не чиста инсталация на всички компоненти както си ги е моя Debian родилотговорът е много много простМЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉

Ulepszony przez Zemanta

Debian OpenLogo

Миналия ден един приятел ми писа че имал проблем с Debian server-a си. По точно не му пазел сессиите повече от 30 минути независимо колко се настройва session.gc_maxlifetime. В общи линии проблема е че Debian са решили да пренапишат поведението на сесиите като вместо garbage collector-а се стартира един cron на всяка 9-та и 39-та минута който почиства старите сесии. Тои се намира в /etc/cron.d/php5

като цяло семпличък скрипт който стартира от своя страна /usr/lib/php5/maxlifetime и в него се намира променливата колко време да е живота на кукито който е 1440 секунди или 24 минути 😉 От тук нататък има 2 варианта или да се спре крон-а и по този начин се прекратява автоматичното чистене което може по късно да се пренастрой от php.ini или направо в самия скрипт да се промени продължителноста на живота на сесиите с променливата max. Аз лично предпочитам втория вариант. Доста по чист е като цяло но има и недостатъкако се презапише файлът промените ни ще се изгубят което си е неприятен факт.

ps. Сега като се замисля вероятно ако се дефинира друго място където да се съхранява сеиината информация чрез самото php би трябвало да излезе извън обхвата на скрипта и по този начин да се използва пак по нормален сесията без да прекъсва грубо.

ini_set('session.gc_maxlifetime', 14400);
 ini_set('session.gc_probability', 1);
 ini_set('session.gc_divisor', 100);
 session_save_path(APP_PARENT_DIR . '/sessions');

Ulepszony przez Zemanta

Dzisiaj opowiem o moich nieszczęściach wokół serwera z Suhosin Łatka i jak Debian Sqeeze sobie z tym radzi. Teraz zacznijmy nieco dalej. Po zainstalowaniu PHP za pośrednictwem systemu pakietów Debian (Stabilny dla innych nie mogę powiedzieć, jak jest nawet) Koniecznie zainstalować i Suhosin mod do niego. Miałem problemy z niektórych Prettywell napisany system PHP i podjąłem kardynalną decyzję zamiast podejmowania usterki systemu i powrót dewelopera, aby pozbyć się poprawki bezpieczeństwa i zapisać sobie bóle głowy. Ogólnie rzecz biorąc, mogę śmiało powiedzieć, że była to jedna z moich najbardziej głupich decyzji. Na początku usuwam PhP5 (w 1999 r-Suhosin zresetowałem serwer www-A i oops dźwigar – Patch-A jest nadal ładowany. Po bardzo krótkim badaniu wykryłem, Że pakiet został skompilowany i stos bezpośrednio do kodu co oznacza, że nie ma zamknięcia lub usunięcia, chyba że ponownie skompilować kod ponownie bez poprawek. Postanawiam, że go pociągam i skompiluję do pakietu Deb. Powiedział zrobić swoje apt-get php5 źródło ciągnie mój obecny kod źródłowy, rozpakowane itp.. Oto mój idealny pomysł, aby pobrać pakiet Sori, aby usunąć poprawki i skompilować go ponownie do pakietu Desian plus dwa małe optymalizacje kompilacji. Mówione gotowe – Usunięto niepotrzebną łatę z Łatka Debiana/Patchesa/suhosin. Usunąłem go, aby nie grać i w Debian/Patches/seria. Do tej pory wszystko wyraźnie i bez problemów. Następnie zwalniam, aby ponownie skompilować pakiet z Debuild ( Debuild ) I zgodnie z oczekiwaniami wysadziłem kompilację z powodu brakujących nagłówków. Oczywiście będą takie braki – Chociaż używam Debian netinstall. Szybko przerobiłem kompilację, W pewnym momencie znowu tylko, Że z dziwnym błędem w Zend/zend_stream. h lub. c Nie pamiętam dokładnie (Jeśli się tym zajmę, mogę później sprawdzić dokładnie, który plik i w jakiej kolejności). Po pewnym nieporozumieniu, co się dzieje i dlaczego Adjeba Rumble w jądrze Zend – Gdzie nie musiałbym huk z jakiegokolwiek powodu i trochę dłużej badania odkrył, że ten problem jest stosunkowo rzadkie i nie ma wiele sygnałów na ten temat. Podejrzewam, że jeden z patchy w sori jest zły ale teraz nie mam nerwów, aby to sprawdzić. Xmmmmm dziwnie Super Dziwne. Prawie postanowiłem skompilować czysto PHP, ale postanowiłem spróbować luster dotdeb да видим там какво ще се случи. Там компилацията умря заради някакви странни зависимости но подмина проблемите в основната част. Което от своя страна е разбираемо нямаше ги те 30-40 кръпки който бяха в стабилния пакет. След няколко дълги и неуспешни опита ми писна и сви свалих ванила пакета и го компилирах с почти debian-ски опции с идеята да пренапише настоящата ми инсталация и като се инсталират нови пакети от хранилката да може да има поведение на пакет инсталиран от хранилището (вероятно поредното не обособно разумно решение). Както очаквах без всички кръпки инсталацията мина гладко. Това е изхода на config.nice файлът ми:

#! /bin/sh
#
# Created by configure

CFLAGS='-g -O2 -fPIC -Wall -fsigned-char -fno-strict-aliasing   -gstabs' \
CXXFLAGS='-g -O2' \
'./configure' \
'--with-apxs2=/usr/bin/apxs2' \
'--prefix=/usr/local/php5' \
'--disable-cgi' \
'--with-config-file-path=/etc/php5/apache2' \
'--with-config-file-scan-dir=/etc/php5/apache2/conf.d' \
'--build=x86_64-linux-gnu' \
'--host=x86_64-linux-gnu' \
'--sysconfdir=/etc' \
'--localstatedir=/var' \
'--mandir=/usr/share/man' \
'--disable-debug' \
'--with-regex=php' \
'--disable-rpath' \
'--disable-static' \
'--with-pic' \
'--with-layout=GNU' \
'--with-pear=/usr/share/php' \
'--enable-calendar' \
'--enable-fileinfo' \
'--enable-hash' \
'--enable-json' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sysvmsg' \
'--enable-bcmath' \
'--with-bz2' \
'--enable-ctype' \
'--without-gdbm' \
'--with-iconv' \
'--enable-exif' \
'--enable-ftp' \
'--enable-dbase' \
'--with-gettext' \
'--enable-mbstring' \
'--with-onig=/usr' \
'--with-pcre-regex' \
'--with-mysql=shared,mysqlnd' \
'--with-mysql-sock=/var/run/mysqld/mysqld.sock' \
'--with-mysqli=shared,mysqlnd' \
'--enable-pdo=shared' \
'--with-pdo-mysql=shared,mysqlnd' \
'--with-pdo-odbc=shared,unixODBC,/usr' \
'--with-pdo-pgsql=shared,/usr/bin/pg_config' \
'--with-pdo-sqlite=shared,/usr' \
'--with-pdo-dblib=shared,/usr' \
'--enable-phar' \
'--enable-shmop' \
'--enable-sockets' \
'--enable-dom' \
'--enable-wddx' \
'--enable-tokenizer' \
'--with-zlib' \
'--with-kerberos=/usr' \
'--with-openssl=/usr' \
'--enable-soap' \
'--enable-zip' \
'--with-mhash=yes' \
'--with-exec-dir=/usr/lib/php5/libexec' \
'--with-system-tzdata' \
'--without-mm' \
'--with-readline=/usr' \
'--without-sybase-ct' \
'--without-sqlite' \
'--without-sqlite3' \
'--without-mssql' \
'--enable-pcntl' \
'--enable-inline-optimization' \
"[email protected]"

Това е конфигурация близка до тази на компилацията на dotdeb. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Ulepszony przez Zemanta

Vector logo of the PHP programming language wi...

Днес ще драсна едно леко четиво за php cache на html. Тука говорим за кеширане на изхода от кода ни а не както съм писал да кешираме скритповете до opcode ниво с Eaccelerator. Така за какво иде речнека да си припомним на бързо работата на php-то. Подаваме заявка на web server-a ни той приема параметрите който подаваме след това той ги подава на php скрипта той се компилира и плюе резултат в html вариант. Това е в доста общи линии. Каква ще е идеята ни тука да прескачаме заявки, да прескачаме големи блокове или не чак толкова големи блокове като директно изрисуваме вече веднъж компилирания изход. Преимуществата са очевиднинамаляна на времето за изпълнение, по малко натоварване и потребление на ресурси. Като цяло не е откриване на топлата вода нито е нещо кой знае колко сложно. Има множество класове за тая цел като Php Pear Cache_Lite който разполага с прекрасна функционалност но аз мисля в бъдеще да си напиша мой с доста по облекчена структура и мой си изисквания към кеширането. Сега ще разгледаме най аборигенския вариант с Output Control Functions. Така нека да кешираме нещо

//start cache all output after that will be saved

ob_start();

//generate output

echo 'Some dynamic output';

echo 'Some other dynamic output ...';

//assign output into variable

$var=ob_get_contents();

//close cache output

ob_end_flush();

Горния код е тривиален но нека да обясним какво стана. Първо декларираме от коя част в кода започва кеширането. След това си генерираме по стандартен начин изхода от кода. След това генерирания изход се присъединява към променлива която ще е достъпна по късно дали през файл някакво или през sessions това си е ваше решение. Накрая изчистваме и прекратяваме кеширането. Съвсем тривиална операция ако да речем геенрирането на кеша минава през огромни блокове от код така можем да спестим доста процесорно време като кешираме за известно време или за една сесия. Вече всичко опира то това какво искате дали да е общодостъпен кеша или да е достъпен за различен потребител.

Ulepszony przez Zemanta