de ĉirkaŭ 2 php semajnoj 5.3 Li eniras la rakonto malrapide sed certe. Sur 11a oni anoncis la finon de lia bontenado kaj kiu estos metita nur sekurecaj flikrimedoj por 1 jaro. esence PHP 5.4 iras en stadioj malnova stabila kaj PHP 5.5 iĝas stabila, kiu estas malpli amuza ĉar ankoraŭ parto de aldonoj kaj nova php kromaĵojn ne funkcias tute korekte sed la versio 5.5 Ĝi estas sufiĉe nova do mi detenas migrado al ĝi.

Do diru ke mi migrado 5.4 el 5.3. Mi antaŭe metis informo por malaktuala funkcioj, kiuj ŝanĝiĝis dramece kaj tiuj kiuj ne plu estos subtenitaj por neniu dramoj ambaŭflanke kiu ne ŝalti aŭ 😉 Do ĉimatene altempigo de komenco de migrado ĉirkaŭ 7 iĝante, ke ekzistas minimuma doloro dum migrado se ne iras glate. Al mia granda surprizo, ĉiu iris pli glate – kompilita via PHP 5.4.17 Mi komencis ĝin kaj Apache-oh ĉielo ĉio estas tie. Rapida rigardo ĉirkaŭ la ŝtipojn ekbruos de depricated aŭ ne entute nekonataj funkcioj – evidente la infanoj faris sian laboron bone. Tiam mi estis nur rekompili kaj suplementoj kiuj estas kompilitaj per la malnova API kiel APC, RAR kaj aliaj. Dua reboot kaj ĉiu endormiĝis. Krom atendi plibonigoj en produktiveco kiel homoj ĉie montrante granda piedfingro iuj tabeloj kie montras kiel PHP 5.4 konsumas malpli RAM kaj ekzekutas skriptoj rapida.

Kelkajn tagojn ekstere XAMPP 1.8.0 hieraŭ post ĝisdatigo de la versio 1.7.7 Mi havis tre interesa problemo. Phpmyadmin-kaj li ne malfermos ridegis 403

aliro malpermesita!


Nova XAMPP sekureco koncepto:

Aliro al la petita objekto estas nur havebla de la loka reto.

Tiu aranĝo povas esti agordita en la dosiero “httpd-xampp.conf”.

Tuj malfermis httpd-xampp.conf kiu min trovas en la / opt / lampp / etc / kroma /, Unuavide ĉio aspektis bone. La reguloj por loka reto estis inter. Krom la malfermo localhost. WTF ??? Mi rigardis la log-kaj vidu miajn aliro estas ekstermita fare konfiguatsiyata. Tie nun kion mi anhelis kaj sincere iom malpli sorton trovis la problemon. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Postulas tutan konceditaj. Ho eureka. Jen nova kontrolo mekanismo kiu eniris en apache 2.4.x. Ĝi donas aliron aŭ rifuzante ajnan tian fajnan, esence imitas Permesu / Deny funcionalidad :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. Post la ŝanĝoj en mi aspektas kiel

<dosierujo “/opt / lampp / phpmyadmin”>
AllowOverride AuthConfig Limo
por permesi,nei
Permesi el ĉiuj
Postulas tutan konceditaj
</dosierujo>

 

Viangi povas provi alian sovaĝan, ekzemple, renomi la dosierujon phpmyadmin io alia kaj ne alias al. Sed estas malbela kaj ne tre signifoplena 🙂

p.s Ili demandis min kial mi uzas XAMPP ne pura instalado de ĉiuj komponantoj kiel ili estas mia Debian naskita – отговорът е много много простМЪРЗЕЛ. Мързи ме да напиша няколко команди после да си пипна конфовете и прочие. Доста по лесно е сваляш целия пакет разархивираш и палиш 😉

Plibonigita per 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');

Plibonigita per Zemanta

Hodiaŭ mi parolos pri la males ĉirkaŭ sola servilo kun Suhosin diakilo kaj kiel debian Sqeeze rilatas al ĝi. Nun ni komencos iom malproksime. Kiam vi instalas php en la Debiana pakita sistemo (stabila por aliaj mi ne povas diri kiel ankoraŭ) vi devas instali kaj suhosin mod ĝin. Mi havis problemojn kun iuj MAH-kadro sistemo skribita en PHP kaj prenis la kardinalo decido anstataŭ fari elpurigi la sistemo kaj reen Raporti Ellaboranto perdi sekurecaj flikrimedoj kaj tiel savi min la penon. Entute mi povas kuraĝe diri, ke tiu estis unu el la plej stultaj decidoj mi iam prenita. Unue forigi modulo php5-suhosin rekomenco retservilo-a kaj oops posteno – diakilo-a estas ankoraŭ ŝarĝita. Post mallonga studo trovi, ke la pako estas kompilita kaj trots rekte en la kodo kiu signifas ke neniu ekskludo aŭ forigo se rekompili la kodo denove sen makulo. Solvi kiuj drapna kaj rekompili al deb pako. Farita dirite fari vian apt-get fonto php5 tirante min ĉi fontkodo, razpaketirva kaj ktp. Tie mia ideala ideo forigi la fonton de la pako forigi la makulon kaj kompili ĝin reen al la Debiana pakaĵo plus unu du malgrandajn optimumigaĵoj en kompilo. diris la afero – forigi nenecesajn diakilo de debian / makuloj / suhosin.patch Mi forigis lin de ludado en debian / makuloj / serio. Ĝis nun ĉio klare kaj sen problemoj. Tiam kuras por kompili pako debuild kaj kiel mi atendis mi blovis kompilo pro mankanta titolaj. Nature estos ajna necesbezonoj – Mi estas ankoraux kun debian netinstall. Rapidan solvon stulteco kuri denove kompilo, ĉe unu poento nur lacigxos denove, ke per stranga eraro en Zend / zend_stream.h aŭ c ne memoras ekzakte (se mi povas trakti poste kontroli precize kion dosieron kaj la linio tondris). Post kelkaj hezitante kio okazas kaj kial la infero povas Rumble de la Zend kerno – kie devus bruegi ial kaj iom pli longa studo trovas ke tiu problemo estas relative malofta kaj ne multaj signoj de tio. Mi suspektas ke unu el la diakiloj en la fonto eraris sed mi ne havas nervojn por kontroli ĝin. Hmmmmm stranga súper stranga. Preskaŭ mi decidis kompili pura php sed mi decidis provi speguloj dotdeb tie por vidi kio okazas. Tie kompilo mortis pro iu stranga toksomanioj sed indulgis la problemoj en la ĉefparto. Kiu siavice estas komprenebla ili faris ilin 30-40 makuloj, kiuj estis en stabila pako. След няколко дълги и неуспешни опита ми писна и сви свалих ванила пакета и го компилирах с почти 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. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Plibonigita per Zemanta

Vector logo of the PHP programming language wi...

Днес ще драсна едно леко четиво за php cache el 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 това си е ваше решение. Накрая изчистваме и прекратяваме кеширането. Съвсем тривиална операция ако да речем геенрирането на кеша минава през огромни блокове от код така можем да спестим доста процесорно време като кешираме за известно време или за една сесия. Вече всичко опира то това какво искате дали да е общодостъпен кеша или да е достъпен за различен потребител.

Plibonigita per Zemanta