Autor wpisu: zleek, dodany: 26.12.2011 22:35, tagi: php, zend_framework, mysql
Autor wpisu: zleek, dodany: 25.12.2011 21:16, tagi: php, zend_framework
Autor wpisu: zleek, dodany: 25.12.2011 00:00, tagi: php, zend_framework, mysql
Autor wpisu: zleek, dodany: 24.12.2011 17:19, tagi: php, apache
Autor wpisu: Tomasz Sh4dow Budzyński, dodany: 16.12.2011 15:30, tagi: php
Jako że web developer goni za nowościami, przyszedł czas na upgrade serwerów testowych (przed wdrożeniem na produkcję). Czy zwykła zmiana wersji mogła odbyć się bez problemów ? Oczywiście że nie. To akurat wie każdy.
Korzystamy dla przechowywania sesji Memcached. Po pierwsze w miarę szybkie i ładnie działa, po drugie sesja jest wsþółdzielona pomiędzy sporo serwerów. Oczywiście logowanie przez SSL’a przestało działać.
Więc w pierwszej kolejności pretensje poszły do naszej aplikacji „Znowu coś zjebaliście !”, później memcache i na koniec serwer. A nie winne były ustawienia PHP. Jeśli posiadacie serwer oparty na Debianie lub jego potomków, sprawdźcie czy macie zainstalowane rozszerzenie Suhosin, a jeśli tak to czy poniższe zmienne macie tak ustawione.
suhosin.session.encrypt = off suhosin.session.cryptua = off
To magiczne rozszerzenie ma skłonności to innego sposobu zapisywania danych w naszej sesji. Jest to string base64 po rozkodwaniu którego znajdujemy jakiś bliżej nie określony zapis binarny. Którego nie mamy jak rozkodować. Sytuacja jest o tyle dziwna, że ta sama domena z SSL’em i bez są traktowane jak by były osobno ale nie. Sesje pomiędzy tak parą domen są osobne. Każda zapisuje się oddzielnie, pod tym samym session_id. Oczywiście parametry sesji są ustawione tak żeby domeny wspólnie korzystały z sesji. Niestety nie udało mi się rozkodować tego co sesja zapisuje. Może jeszcze znajdę chwile to postaram się zrozumieć to zjawisko. W każdym bądź razie. Rozszerzenie wyłączyć lub zmienić ustawienia i problemy znikają.
Autor wpisu: batman, dodany: 09.12.2011 08:00, tagi: php
Zend Developer Cloud w przeciwieństwie do PHP Fog oferuje możliwość logowania się do chmury przy pomocy protokołu SFTP. Stwarza to dodatkowe możliwości deploy’u aplikacji do chmury. Jeśli korzystacie z PHPStorm i z jakiegoś powodu nie chcecie/nie możecie używać Gita do przesyłania aplikacji do chmury, deploy wykonacie przy pomocy wbudowanego narzędzia Deployment.
Zanim zaczniemy, musimy przygotować nowy projekt. W tym celu w serwisie my.phpcloud.com należy utworzyć nową aplikację (nazwa na załączonym obrazku jest przykładowa, możecie użyć własnej).
Następnie musimy sklonować repozytorium projektu (jest to jedyny raz, gdy użyjemy gita). W celu sklonowania repozytorium najlepiej skorzystać z wbudowanych w PHPStorm narzędzi.
Jedyne co nam pozostało do zrobienia, to skonfigurowanie narzędzia Deployment. Aby to zrobić, z menu Tools wybieramy opcję Deployment. W oknie, które się pojawi, uzupełniamy nazwę hosta, zmieniamy port na 22, podajemy ścieżkę do klucza prywatnego będącego parą do klucza publicznego przesłanego do chmury, a na końcu wybieramy katalog root.
W zakładce Mappings musimy wskazać katalogi, które mają się synchronizować.
Ostatnią czynnością jaką musimy wykonać jest ustawienie nowoutworzonej konfiguracji jako domyślnej oraz włącznie opcji automatycznego uploadu. Wystarczy teraz, że dodamy, usuniemy lub zmodyfikujemy plik, a zostanie on automatycznie zsynchronizowany z projektem w chmurze. Jeśli okaże się, że pliki nie synchronizują się automatycznie, niezbędne będzie jednorazowe ręczne wysłanie plików.