От около 2 седмици php 5.3 влиза във историята бавно но сигурно. На 11-ти обявиха края на поддръжката му и че ще бъдат пускани само кръпки по сигурността в продължение на 1 Έτος. В общи линии 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 родилотговорът е много много простМЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉

Ενισχυμένος από 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');

Ενισχυμένος από Zemanta

Σήμερα θα πω για τα δεινά μου γύρω από ένα διακομιστή με Σουχοσίν Ενημερωμένη έκδοση κώδικα και πώς Debian Sqeeze αντιμετωπίζει με αυτό. Τώρα ας ξεκινήσουμε λίγο πιο μακριά.. Όταν εγκαθιστάτε php μέσω του συστήματος πακέτων του Debian (Σταθερή για τους άλλους δεν μπορώ να πω πώς είναι ακόμη) Αναγκαστικά μπορείτε να εγκαταστήσετε και Suhosin mod σε αυτό. Είχα προβλήματα με κάποια Prettywell γραπτή PHP σύστημα και πήρα την απόφαση καρδινάλιος αντί να κάνει μια δυσλειτουργία του συστήματος και την επιστροφή του έργου για να απαλλαγούμε από το έμπλαστρο ασφαλείας και να σώσει τον εαυτό μου πονοκεφάλους. Σε γενικές γραμμές, μπορώ να πω με τόλμη ότι ήταν μια από τις πιο ανόητες αποφάσεις μου που ελήφθησαν ποτέ. Στην αρχή, καταργώ το PhP5-Suhosin μπορώ να επαναφέρετε το διακομιστή Web-Α και ουπς δοκό – Η ενημερωμένη έκδοση κώδικα-Α εξακολουθεί να είναι φορτωμένη. Μετά από μια πολύ σύντομη μελέτη, εντόπισα, Ότι το πακέτο έχει συνταχθεί και με τη στοίβα απευθείας στον κώδικα που σημαίνει ότι δεν υπάρχει τερματισμός ή αφαίρεση, εκτός αν μεταγλωττίσετε ξανά τον κώδικα χωρίς τις ενημερωμένες εκδόσεις κώδικα. Решавам че ще го дръпna и прекомпилирам до deb пакет. Речено сторено правя си apt-get source php5 дърпа ми се настоящия сорс код, разпакетирва се и прочие. Εδώ είναι η τέλεια ιδέα μου να μεταφορτώσω τη συσκευασία Sori για να αφαιρέσει τα μπαλώματα και να το συντάξει πάλι σε μια desian συσκευασία συν δύο μικρές βελτιστοποιήσεις κατασκευής. Προφορική γίνει – премахнах ненужния пач от debian/patches/suhosin.patch премахнах го да не играе и в debian/patches/series. До тук всичко ясно и без проблеми. След това пускам да се компилира пакета с debuild Και όπως ήταν αναμενόμενο ανατίναξα τη συλλογή λόγω των ελλειπόντων κεφαλίδων. Φυσικά θα υπάρξουν τέτοιες ελλείψεις – Αν και είμαι χρησιμοποιώντας Debian netinstall. Ξανακάνω γρήγορα τη συλλογή, Σε κάποιο σημείο και πάλι μόνο, Ότι με ένα παράξενο λάθος στο Zend / zend_stream. h ή. γ Δεν θυμάμαι ακριβώς (Αν με ανησυχεί, μπορεί αργότερα να ελέγξω ακριβώς ποιο αρχείο και με ποια σειρά). Μετά από κάποια παρεξήγηση τι συμβαίνει και γιατί η Adjeba Rumble στον πυρήνα Zend – Όπου δεν θα πρέπει να βουίζει για οποιοδήποτε λόγο και λίγο μεγαλύτερη μελέτη ανακάλυψε ότι αυτό το πρόβλημα είναι σχετικά σπάνιο και δεν υπάρχουν πολλά σήματα γι 'αυτό. Υποψιάζομαι ότι ένα από τα μπαλώματα στο sori είναι λάθος, αλλά τώρα δεν έχω κανένα θράσος για να το ελέγξετε. Xmmmmm παράξενα σούπερ παράξενο. Αποφάσισα σχεδόν να καταρτίσει μια καθαρά PHP, αλλά αποφάσισα να δοκιμάσω τους καθρέφτες του dotdeb Δείτε εκεί τι συμβαίνει. Εκεί, η συλλογή πέθανε λόγω ορισμένων παράξενων εξαρτήσεων, αλλά τα προβλήματα στο κύριο μέρος. Το οποίο με τη σειρά του ήταν κατανοητό ότι δεν ήταν. 30-40 Μπαλώματα που βρίσκονταν στη σταθερή συσκευασία. Μετά από μερικές μακρές και ανεπιτυχείς προσπάθειες πήρα κουρασμένος και έβγαλα το πακέτο βανίλιας και το σύνταξα με σχεδόν τις επιλογές debian-σκι με την ιδέα να ξαναγραφτεί η τρέχουσα εγκατάστασή μου και η εγκατάσταση των νέων συσκευασιών από τον τροφοδότη μπορεί να εγκαταστήσει τη συμπεριφορά της συσκευασίας από την αποθήκη (Πιθανώς μια άλλη μη διαφοροποιημένη λύση). Όπως περίμενα χωρίς όλα τα μπαλώματα η εγκατάσταση πήγε ομαλά. Αυτή είναι η έξοδος του config. ωραίο αρχείο μου:

#! /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. Η επιλογή πρόθεμα, όπου τα αρχεία βιβλιοθήκη PHP θα αναπτυχθεί, είναι ως βάση και πιο σημαντικό.. Καθώς και τις άλλες φορές να τα διορθώσει σύμφωνα με το σύστημά σας, έτσι ώστε να μην αισθάνονται την κατασκευή με την αλλαγή των δρόμων.

Ενισχυμένος από Zemanta

Vector logo of the PHP programming language wi...

Днес ще драсна едно леко четиво за php cache на html. Тука говорим за кеширане на изхода от кода ни а не както съм писал да кешираме скритповете до opcode ниво с eΕπιταχυντής. Така за какво иде речнека да си припомним на бързо работата на 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 това си е ваше решение. Накрая изчистваме и прекратяваме кеширането. Съвсем тривиална операция ако да речем геенрирането на кеша минава през огромни блокове от код така можем да спестим доста процесорно време като кешираме за известно време или за една сесия. Вече всичко опира то това какво искате дали да е общодостъпен кеша или да е достъпен за различен потребител.

Ενισχυμένος από Zemanta