Wszystkie te funkcje od ponad 10 lat zawiera program EditPlus którego używam na co dzień.

Prócz PHP programuje w kilku innych językach, gdzie używam często środowiska opartego o Eclipse, bądź innych rozbudowanych IDE. Dlatego też, raz na jakiś czas wpadam na genialny pomysł żeby odstawić EditPlus’a i poszukać godnego następcy. Wybór zazwyczaj pada na najnowsze wersje najpopularniejszych IDE (np: PDT, Zend Studio i inne).
Dzisiaj pobrałem Zend Studio 7.0. Pierwsze co zrobiłem po zainstalowaniu to testy funkcji na zakładce “Remote Systems“. Zapowiada się bardzo ciekawie, bo wśród zdalnych systemów znajdziemy FTP, SSH, telnet, coś o magicznej nazwie Linux, Unix, Windows.

Po skonfigurowaniu konta FTP, wchodzę sobie do katalogu zawierającego średniej wielkości projekt (z dużą ilością obrazków z systemu newsowego) i eksportuje go do projektu w Zend Studio. Eksport taki trwa około 30 minut. Zend biega po całym FTP i zapisuje sobie jego strukturę. Dodam tylko, że z powodzeniem wykluczyć mogę problemy z serwerem czy łączem.

Po wyeksportowaniu projektu (poprzez opcje “Create remote Project“) okazuje się, że Zend nie potrafi uzupełniać najprostszych funkcji (np: mysql_*). Pomyślałem, że może musi sobie całość przeparsować i to może trochę potrwać. Oczywiście to było bardzo naiwne z mojej strony. Z jednoplikowym projektem sytuacja wygląda tak samo.

Stwierdziłem, że skasuje mój “Remote project” i zrobię go od nowa – może czegoś nie zaznaczyłem itd. Podczas kasowania projektu (PPM na nazwie w oknie “PHP Explorer” > Delete) widzimy tradycyjne okienko z Eclipse z informacją “Delete project contents on disk (cannot be undone)“, a pod tym między innymi przycisk “Preview“. Kliknąłem “Preview” żeby zobaczyć co zostanie skasowane (bez zaznaczonego ww. checkboxa) i czekam, czekam, czekam … czekam. Widzę, że Zend znowu biega po całym ftpie, i jak już skończył (kilkanaście minut) to pokazało się “No preview available”. Myśląc, że to już koniec niespodzianek z Zend’em klikam “Ok” (nadal ww. checkbox nie zaznaczony), a Zend zaczyna kasować całą zawartość na serwerze – po prostu genialnie. Pozwoliłem mu dokończyć dzieła (15 minut). Ciekawe co by zrobił gdybym jednak kazał mu skasować ten projekt lokalny.

Kolejną ciekawostką, którą zaobserwowałem pisząc ten tekst jest fakt, iż Zend bardzo lubi sobie ciągle rozmawiać z naszym FTP. Dodałem do lokalnego projektu jeden plik zdalny. Plik ten ma już poprawne uzupełnianie kodu, a więc rozwiązało to mój poprzednie problem z projektami zdalnymi. Podczas pisania w tym pliku wyrazu “mysql” Zend wydał serwerowi ponad 40 komend. Co chwila wysyła NOOP, CWD na katalog w którym niezmiennie się znajduje i LIST -a. Nie ma to jak optymalizacja …

Podsumowując, nie chciał bym tutaj zrażać do tego typu oprogramowania. Sam doceniam bardzo porządne uzupełnianie składni, debugging i profiling i inne opcje Zend Studio. Niestety Zend od dawien dawna nie potrafi opracować dobrego modelu pracy zdalnej – modelu w którym nie trzeba mieć na własnym komputerze serwera http, bazy danych i innych dodatków.

Być może na rynku aplikacji integracyjnych prócz Weborb i AMFPHP wkrótce pojawi się rozwiązanie z Zend Framework.

Zobacz więcej na temat współpracy Zend i Adobe

Jest sporo nowości w stosunku do poprzedniej finalnej wersji. Można o nich posłuchać z ust managera Zend Framework Tram:

Linki:
Pobierz Zend Framework 1.6
News mówiący o przyczynach nawiązania współpracy właśnie z Dojo

• Improved fix for MOPB-02-2007.
• Fixed an integer overflow inside chunk_split(). Identified by Gerhard Wagner.
• Fixed integer overlow in str[c]spn().
• Fixed regression in glob when open_basedir is on introduced by #41655 fix.
• Fixed money_format() not to accept multiple %i or %n tokens.
• Addded “max_input_nesting_level” php.ini option to limit nesting level of input variables. Fix for MOPB-03-2007.
• Fixed INFILE LOCAL option handling with MySQL – now not allowed when open_basedir or safe_mode is active.
• Fixed session.save_path and error_log values to be checked against open_basedir and safe_mode (CVE-2007-3378).
• Fixed bug #43010 (Fixed regression in imagearc with two equivelent angles).
• Fixed bug #41765 (Recode crashes/does not work on amd64).
• Fixed bug #41630 (segfault when an invalid color index is present in the image data).
• Fixed bug #41628 (PHP settings leak between Virtual Hosts in Apache 1.3).
• Fixed bug #38798 (OpenSSL init corrected in php5 but not in php4).

Większość z ww. modyfikacji ma istotny wpływ na bezpieczeństwo środowiska w którym się znajduje.

Na potrzeby niniejszej konfiguracji użyłem:

• Linux Slackware w wersji 12. Starałem się nie używać ustawień i pakietów pochodzących z dystrybucji, żeby rozwiązanie było jak najbardziej uniwersalne
• Apache w wersji 2.2.6
• FastCGI w wersji 2.4.6
• PHP w wersji 4.4.7 i 5.2.5

Przyjąłem również kilka założeń:

• Skrypty PHP powinny być uruchamiane w zamkniętym środowisku (np: chroot() albo open_basedir())
• Skrypty PHP powinny być uruchamiane z uprawnieniami właściciela pliku/virtualhosta
• Każdy użytkownik powinien mieć indywidualny folder tmp i folder przechowywania plików sesji
• Każdy użytkownik sam może wybrać wersji PHP
• Dla każdego virtualhosta powinien istnieć oddzielny plik php.ini
• Tworzone rozwiązanie powinno być jak najbardziej uniwersalne. Jednocześnie powinno oferować administratorowi wygodę zarządzania

Instalacja Apache:

Apache wraz z modułem suexec potrafi uruchamiać skrypty CGI z uprawnieniami użytkownika. Model bezpieczeństwa suexec wymaga deklarowania zmiennych środowiskowych, które mają być przekazywane do CGI. Większość zmiennych środowiskowych np.: REQUEST_URL, DOCUMENT_ROOT itp. są wpisane na stałe do pliku support/suexec.c, jednak brakuje tam zmiennych dla PHP, które pomagają mu współpracować z modułem FastCGI. Musimy je ręcznie dopisać, a więc otwieramy plik support/suexec.c w ulubionym edytorze tekstowym i znajdujemy kod:

Dopisujemy przed linijką zawierającą AUTH_TYPE:

Plik wynikowy powinien wyglądać następująco:

Dzięki wykonanej modyfikacji suexec będzie przekazywał zmienne środowiskowe, które ustawi FastCGI, do wrappera PHP (w dalszej części artykuły opisze obie zmienne i dlaczego trzeba było wprowadzić tą poprawkę).

Teraz możemy przystąpić do rzeczywistej konfiguracji Apache. Uruchamiamy komendę:

Opis parametrów:

• –enable-so: włączenie mechanizmu DSO
• –with-suexec-caller: użytkownik z którego będzie wywoływany suexec. Należy tutaj wpisać nazwę użytkownika na którym działa Apache
• –with-suexec-docroot: ścieżka w której znajdują się wszystkie skrypty PHP uruchamiane przez suexec
• –with-suexec-logfile: plik do którego suexec będzie logował. Należy pamiętać o utworzeniu takiego pliku i nadaniu mu uprawnień do zapisu dla użytkownika na którym działa Apache. Należy mieć też na uwadze konieczność rotowania tego pliku – Apache się tym nie zajmuje
• –enable-suexec: włączenie mechanizmu suexec
• –enable-cgi:włącza obsługę CGI – niezbędne do konfiguracji PHP jako CGI
• –with-suexec-bin: ścieżka do pliku suexec w naszym systemie. Plik ten może znajdować się w dowolnym miejscu

Jeżeli nie dodałeś żadnego layoutu ustawień (–enable-layout=LAYOUT) podczas konfigurowania Apache, pliki zostaną umieszczone w katalogu /usr/local/apache2. Jeżeli zmieniłeś layout, pamiętaj o zmianie ścieżki do pliku suexec (–with-suexec-bin).

Instalacja FastCGI:

Konfiguracja FastCGI sprowadza się do wykonywania instrukcji instalacyjnych z pliku INSTALL.AP2. Należy pamiętać o zmianie ścieżki top_dir w przypadku innej konfiguracji Apache. We wskazanym katalogu powinien się znaleźć plik build/special.mk:

Instalacja PHP:

Instalacja obu wersji PHP przebiega podobnie dlatego opiszę tylko jedną wersję w tym miejscu. W przypadku PHP 4 zalecał bym tylko zmianę prefixu na /usr/local/php4. Dalsza część artykułu zawiera konfiguracje dla systemu z obiema wersjami PHP.

Celowo nie dodawałem tutaj parametru –sysconfdir, który wskazuje na miejsce szukania domyślnego pliku php.ini. Będę używał parametru -c do wskazania pliku php.ini. Dowiedz się więcej o kolejności ładowania plików php.ini z mojego artykułu.

Opis parametrów:

• –prefix: prefix instalacji ustawiłem na /usr/local/php5 gdyż równolegle będziemy instalować php4 i dobrze by było gdyby dwie wersji nie wchodziły sobie w drogę
• –enable-force-cgi-redirect: parametr ten zabezpiecza przed wywołaniem skryptu PHP poprzez link bezpośredni do skryptu FastCGI w folderze fcgi. Skrypt PHP zostanie wykonany tylko i wyłącznie jeżeli odwołanie do parsera zostało wykonane przez Apache
• –enable-fastcgi: włączenie obsługi FastCGI w parserze PHP

Zanim wykonasz poniższe komendy utwórz katalog /usr/local/php5.

W tym momencie zakończyliśmy instalacje i podstawową konfigurację niezbędnego programowania. Przystąpmy zatem do dalszej konfiguracji.

Konfiguracja Apache:

Plik konfiguracyjny Apache (httpd.conf) powinien zawierać między innymi takie ustawienia:

Opis parametrów:

• FastCgiWrapper: w tym miejscu deklarujemy wrapper dla FastCGI. Zamiast suexec możemy użyć np. cgiwrap albo sbox. Jeżeli chcemy użyć tego samego wrapper co Apache możemy ustawić tą opcję na “On”
• FastCgiConfig: deklarujemy w jaki sposób ma się zachowywać FastCGI
• -initial-env PHP_FCGI_CHILDREN=1: Ustawia zmienną środowiskową PHP_FCGI_CHILDREN która poprzez wrapper (np.: suexec) przekazujemy do PHP. Jeżeli nie zmodyfikowali byśmy źródeł suexec , zmienna ta została by wycięta. PHP_FCGI_CHILDREN określa ile procesów potomnych ma obsługiwać żądania PHP dla jednego virtualhosta
• -initial-env PHP_FCGI_MAX_REQUEST=5000: Zmienna ta określa maksymalną ilość żądań po których dany proces zostanie zakończony i uruchomiony w razie potrzeby od nowa
• -singleThreshold 90: Parametr przyjmuje wartości liczbowe od 0 do 100. FastCGI na tej podstawie określa czy dany proces ma być utrzymywany (wartość bliższa 1) czy zabity (bliżej 100) jeżeli nie jest już wykorzystywany. Jeżeli zależy Ci się na oszczędności pamięci ustaw ten parametr bliżej 100. Ustawienie na 0 zapobiegnie wyłączaniu ostatniego procesu potomnego
• -killInterval 300: Wartość parametru w sekundach, określa po jakim czasie bezczynności proces ma zostać zabity
• -autoUpdate: Powoduje sprawdzanie daty skryptów FastCGI. Jeżeli któryś z nich zostanie zaktualizowany, FastCGI zabije proces i uruchomi go od nowa
• -idle-timeout 240: Czas w sekundach który ma skrypt PHP na uruchomienie i rozpoczęcie zwracania wyników użytkownikowi
• -pass-header HTTP_AUTHORIZATION: Przekazania nagłówków uwierzytelniania HTTP do CGI. Standardowo nagłówki te nie są przekazywane

Przyjąłem, że każdy virtualhost posiada swój katalog w /var/www. Struktura prezentuje się następująco:
/var/www/host1.example.com
/var/www/host1.example.com/htdocs – główny folder dostępny przez http
/var/www/host1.example.com/htdocs/fcgi – folder ze skryptami FastCGI
/var/www/host1.example.com/tmp – folder przeznaczony na pliki sesji i pliki tymczasowe

Konfiguracja virtualhosta:

Opis parametrów:

• SuexecUserGroup v1 v1: określa systemowego użytkownika i grupę na którą suexec ma przenieść uprawnienia
• <Location /fcgi/php5>…</Location>: Zarejestrowanie pliku /fcgi/php5 jako skryptu FastCGI
• <Location /fcgi/php4>…</Location>: Jw. tylko, że dla pliku /fcgi/php4
• <Directory>…</Directory>: Ustawienia katalogu fcgi. Należy tutaj szczególną uwagę zwrócić na “Options None”. Zabezpiecza to przed możliwością uruchamiania programów niż zadeklarowane w <Location …>. Dodatkowo opcja “AllowOverride None” zabezpiecza przed możliwością zmiany tych ustawień z poziomu pliku .htaccess
• AddHandler php5-fastcgi .php: Ustawia domyślny interpretator dla plików .php na PHP 5. Gdyby użytkownik chciał zmienić wersje PHP na inna wystarczy, że sam we własnym zakresie stworzy plik .htaccess i wpisze do niego AddHandler php4-fastcgi .php
• Action php5-fastcgi /fcgi/php5: Deklaracja skryptu FastCGI dla PHP 5
• Action php4-fastcgi /fcgi/php4: Deklaracja skryptu FastCGI na PHP 5

Trzy opisane na końcu parametry można umieścić poza sekcją <VirtualHost>…</VirtualHost> czyniąc z nich ustawienia globalne dla serwera.

Teraz utworzymy skrypty FastCGI zadeklarowane w konfiguracji Apache. Skrypty te musimy utworzyć dla każdego virtualhosta w katalogu htdocs/fcgi.
Dla PHP 5 tworzymy plik htdocs/fcgi/php5:

Dla PHP tworzymy plik htdocs/fcgi/php4:

Niektórzy zadadzą sobie teraz pytanie “Po co dodawać każdemu katalog fcgi razem ze skryptami skoro mogę zrobić jeden katalog i podlinkować go każdemu?”.

Odpowiedź leży w źródłach suexec, które edytowaliśmy na początku. Model bezpieczeństwa suexec jest bardzo restrykcyjny i dokładnie porównuje uprawnienia uruchamianych programów razem z folderami virtualhosta. Jeżeli chodź jeden z testów nie będzie zgodny, skrypt nie zostanie uruchomiony. Rozwiązaniem jest modyfikacja źródeł suexec albo rozwiązanie problemu poprzez kopiowanie skryptów FastCGI do każdego virtualhosta. Pamiętaj o zmianie właściciela plików php4 i php5.

W tym miejscu powinienem powrócić jeszcze do modyfikacji suexec, którą wykonaliśmy na początku. Nic nie stało na przeszkodzie żebyśmy dopisali do utworzonych przed chwilą skryptów export zmiennych globalnych np.:

Modyfikację tą wprowadzaliśmy jednak, żeby istniała możliwość ustawienia tych parametrów globalnie. Jeżeli jeden z virtualhostow wymaga innej konfiguracji to możemy zmodyfikować te wartości właśnie poprzez export jak na ww. przykładzie.

Pliki konfiguracyjne php.ini:

Żeby cała ta konfiguracja zdała egzamin musimy w przygotować indywidualne pliki php.ini dla każdego virtualhosta. W przypadku PHP 5 sprawa jest odrobinę ułatwiona. Temat ten opisałem w artykule “Uproszczenie w konfiguracji PHP 5 per virtualhost“.W pliku konfiguracyjnym obu wersji PHP powinny się znaleźć:

Finalizacja:

Na koniec pozostaje nam kilka problemów do rozwiązania, a mianowicie:

• użytkownik może zmodyfikować zawartość skryptów znajdujących się w htdocs/fcgi, a co za tym idzie, dajemy mu dostęp do powłoki systemu, czego z pewnością większość z Was wolała by uniknąć
• użytkownik może zmienić/skasować plik php.ini. Ma wtedy dostęp do modyfikacji spersonalizowanych wartości open_basedir, error_log, session.save_path, disable_functions itp.

Żeby rozwiązać te problemy, należało by zabrać użytkownikowi możliwość edycji plików w katalogu htdocs/fcgi. Gdy zabierzemy mu uprawnienia poprzez zmianę właściciela, suexec bardzo szybko przypomni nam o tym fakcie. Rozwiązanie jakie znalazłem niestety nie jest eleganckie, ale za to jest skuteczne.

Użytkownicy systemu plików ext2/3 mogą nadać atrybut +i dla katalogu htdocs/fcgi poprzez chattr +i fcgi. Uniemożliwi to wprowadzanie zmian na folderze fcgi (razem z jego zawartością) dla wszystkich użytkowników systemu. Tak założone atrybut +i zdejmuje tylko i wyłącznie root.

Change log artykułu:

Będę się starał uaktualniać ten artykuł, a więc w tym miejscu opisze przyszłe zmiany.
25/02/2008 19:38 – Usunięcie niepoprawnych spacji z konfiguracji VirtualHost.
04/02/2008 17:41 – Zmieniłem nazwę “apache2.conf” na “httpd.conf” celem poprawienia zgodności z domyślną konfiguracją Apache.
30/01/2008 20:28 – Zmiana <IfModule> na </IfModule> w konfiguracji Apache.
25/01/2008 12:26 – Poprawka związana z błędną nazwa foldera w przykładowej konfiguracji Apache. Zamienione “fcgi-bin” na “fcgi”.
30/12/2007 16:45 – Publikacja pierwszej wersji

Poniżej opisanych dyrektyw, możemy posługiwać się zmiennymi ${main_domain} i ${main_root_dir} np.: w taki sposób:

Niestety opcja ta nie jest dostępna w PHP 4 i w związku z zamknięciem rozwoju tej wersji, nie zostanie już dodana.

Po krótkim debugowaniu aplikacji okazało się w jakiej kolejności PHP poszukuje plików ini:

Wyżej wymieniona kolejność jest taka sama dla PHP uruchamianego z poziomu FastCGI/CGI. W przypadku pominięcia parametru --enable-fastcgi zmianie ulega nazwa pliku php-cgi-fcgi.ini na php-cgi.ini.

W przypadku PHP uruchomionego jako moduł Apache sprawa ma się trochę inaczej:

(PHP było skompilowane z opcją --sysconfdir=/etc/php5/apache.)

Niestety testy które przeprowadziłem wykazały, że PHP po znalezieniu pierwszego pliku ini pomija dalsze lokalizacje. Planowałem na podstawie tego mechanizmu dać użytkownikom możliwość posiadania własnego pliku php.ini z gwarancją, iż niektóre parametry były by zawsze globalnie nadpisywane (np: open_basedir, czy disable_functions).

W projekcie zastosowałem pobieranie danych do tworzenia menu z zewnętrznego pliku XML. Plik XML wyglądał tak:

Jako, że menu było w jednej linii to obliczałem przy użyciu metody TextFormat.getTextExtent() jakich rozmiarów powinno być pole tekstowe, żeby pomieścić tekst. Wszystko działało idealnie do momentu kiedy nie zrobiłem zewnętrznego pliku spełniającego funkcje loadera. Po załadowaniu strony z loadera całe menu się rozjechało – teksty nachodziły na siebie, pola były za małe.

Okazało się, że flash (sprawdzałem na wersji CS3) ma wspaniałą przypadłość:
Jeżeli używasz TextFormat.getTextExtent() na czcionkach dołączonych do animacji, to te same czcionki musisz dołączyć do loadera (nawet jak ich tam nie używasz). W przeciwnym wypadku flash nie będzie potrafił poprawnie policzyć rozmiaru dla pola tekstowego.