ongeveer 2 php weken 5.3 Hij gaat het verhaal langzaam maar zeker. Op 11 kondigde ze het einde van het onderhoud en dat zal worden gebracht security patches voor 1 jaar. In principe PHP 5.4 gaat in fasen oude stal en PHP 5.5 wordt stabiel, dat is minder leuk, want nog steeds deel uit van de aanvullingen en nieuwe php plugins niet helemaal correct, maar de versie werken 5.5 Het is vrij nieuw, dus ik zal onthouden van migratie te.

Dus laten we zeggen voor mij om de migratie 5.4 van 5.3. Ik had eerder gezet informatie voor verouderde functies, die drastisch zijn veranderd en mensen die niet meer zonder drama's aan beide kanten die niet ontbranden of 😉 Dus vanmorgen timing van de start van de migratie in de buurt worden gehandhaafd 7 steeds, dat er minimale pijn tijdens de migratie zo niet soepel gaan. Tot mijn grote verrassing, alles verliep soepeler – gecompileerd PHP 5.4.17 Ik begon het en apache-oh hemel alles is er. Een snelle blik in de buurt van de logs zal brullen van depricated of helemaal niet onbekend functies – uiteraard de jongens hebben hun werk goed gedaan. Toen werd ik gewoon opnieuw compileren en supplementen die worden samengesteld met de oude API als APC, RAR en andere. Tweede reboot en alles viel in slaap. Apart verwachten verbetering van de productiviteit als mensen overal te wijzen grote teen enkele tabletten, waar laat zien hoe PHP 5.4 verbruikt minder RAM en uitvoert scripts sneller.

Een paar dagen uit XAMPP 1.8.0 gisteren na upgrade van versie 1.7.7 Ik had nogal een interessant probleem. Phpmyadmin-en hij gaat niet open en brulde met 403

Toegang verboden!


Nieuwe XAMPP beveiligingsconcept:

De toegang tot het gevraagde object is alleen beschikbaar vanaf het lokale netwerk.

Deze instelling kan worden geconfigureerd in het bestand “httpd-xampp.conf”.

Meteen opende httpd-xampp.conf die mij in de map / opt / lampp / etc / extra /, Op het eerste gezicht leek alles goed. De regels voor het lokale netwerk behoorden. Afgezien van de opening localhost. WTF ??? Ik keek naar de log-en zie dat mijn toegang wordt afgesneden door konfiguatsiyata. Hier nu wat ik hapte naar adem en eerlijk gezegd wat minder geluk vond het probleem. Na het doorlopen van httpd.conf-en zag in Toestaan ​​/ Weigeren clausules één laatste bestelling Vereisen dat alle verleende. Oh eureka. Dit is een nieuwe controle-mechanisme dat aangegane Apache 2.4.x. Het geeft toegang tot of een dergelijke boete weigeren, in principe bootst Toestaan ​​/ Weigeren functionaliteit :). Om het probleem op te lossen toe te voegen vereisen alle verleende richtlijnen voor de map / opt / lampp / phpmyadmin. Na de veranderingen in mij eruit ziet

<directory “/opt / lampp / phpmyadmin”>
AllowOverride AuthConfig Limit
Bestel toestaan,ontkennen
Toestaan ​​van alle
Vereisen dat alle verleende
</directory>

 

Viangi kan een ander wilde proberen, bijvoorbeeld naar de map phpmyadmin iets andere naam geven en niet alias. Maar het is lelijk en niet erg zinvol 🙂

P.S Ze vroegen me waarom ik XAMPP geen schone installatie van alle componenten te gebruiken als ze is mijn Debian geboren – Het antwoord is heel simpel – luiheid. Lazy me om een ​​paar commando's te schrijven toen raakte zijn konfovete etc.. Veel gemakkelijker is het raken van het hele pakket en pak je licht 😉

Versterkt door 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');

Versterkt door Zemanta

Vandaag heb ik praten over de ellende rond een enkele server met suhosin patch en hoe Debian Sqeeze deal mee. Nu beginnen we een beetje afstand. Als je php installeren op de Debian verpakkingssysteem (stabiel voor anderen kan ik niet zeggen hoe nog) u moet installeren en suhosin mod te. Ik had problemen met sommige MAH frame systeem geschreven in php en nam de kardinaal beslissing in plaats daarvan te doen debuggen van het systeem en de rug Report Developer om security patches te verliezen en daarmee mezelf redden de moeite. Over het algemeen kan ik met vertrouwen zeggen dat dit een van de meest domme beslissingen die ik ooit genomen. Op het eerste module verwijderen php5-suhosin restart web server-a en oops bericht – patch-a is nog steeds geladen. Na een korte studie vinden, dat het pakket is samengesteld en draaft direct in de code, wat betekent dat er geen uitsluiting of verwijdering, tenzij opnieuw compileren van de code opnieuw zonder patch. Lossen die drapna en opnieuw compileren om deb-pakket. Gedaan Zo gezegd, zo doe je apt-get source php5 trok me deze broncode, razpaketirva en etc.. Hier mijn ideaal idee om de bron van het pakket te verwijderen om de patch te verwijderen en te compileren het terug naar de Debian-pakket plus één twee kleine optimalisaties in compilatie. zei gedaan – elimineren onnodige patch van debian / flarden / suhosin.patch Ik verwijderde hem van het spelen in debian / flarden / serie. Tot nu toe alles duidelijk en zonder problemen. Dan start de verpakking te compileren debuild en als ik had verwacht ik blies compilatie vanwege ontbrekende headers. Uiteraard zullen er tekorten – Ik ben nog steeds met debian NetInstall. Quick fix domheid weer compilatie run, op een gegeven moment pas weer flauw, die met een vreemde fout in Zend / zend_stream.h of .c niet precies herinneren (als ik kan omgaan later precies welk bestand te controleren en de lijn donderde). Na enige twijfel wat er gebeurt en waarom de hel kan denderen van de Zend kern – waar het zou moeten rommelen om welke reden en een beetje langer studie vindt dat dit probleem is relatief zeldzaam en niet veel tekenen van. Ik vermoed dat een van de patches in de bron verkeerd was, maar ik heb geen zenuwen om het te controleren. Hmmmmm raar super raar. Bijna heb ik besloten om pure php compileren maar ik besloot om spiegels te proberen dotdeb er te zien wat er gebeurt. Er compilatie overleed als gevolg van een aantal vreemde verslaving, maar spaarde de problemen in de hoofdtekst. Die op zijn beurt is begrijpelijk dat ze deden hen 30-40 Patches die in stabiele pakket waren. Na een aantal lange en mislukte pogingen werd ik moe en uitgeschakeld mijn vanille-pakket en het compileren met bijna debian-ski mogelijkheden met het idee om mijn huidige systeem herschrijven en installeren van nieuwe pakketten van de feeder-pakket geïnstalleerd vanaf de repository kunnen gedragen (waarschijnlijk een andere gedifferentieerde geen redelijke oplossing). Zoals ik had verwacht, zonder vlekken installatie verliep vlot. Dit is het resultaat van mijn config.nice bestand:

#! /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]"

Deze configuratie is vergelijkbaar met die van samenstelling dotdeb. Като основаното и най важно е prefix опцията където ще се разполагат файловете с библиотеките на php. Него както и другите пъти ги коригирайте според вашата система така че да не се усети компилацията с промяна на пътищата.

Versterkt door Zemanta

Vector logo of the PHP programming language wi...

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

Versterkt door Zemanta