Witam wszystkich. Dzisiejszy wpis to suma pomysłów na co najmniej trzy artykuły, które przeleżały gdzieś z tyłu głowy przez ostatnie 2 miesiące. Nadal pracuję nad projektami o których wspominałem w poprzednich wpisach, cały czas rozbudowując, optymalizując i stając na głowie, żeby wszystko działało jak najlepiej. W końcu mam możliwość technologicznie spełnić się opracowując różne rozwiązania, które autentycznie są używane, a nie tylko chowane do szuflady, czy też jak to się modnie mówi „do portfolio”. :)

 

Pierwsza sprawa: wydajność Doctrine i kwestia PHP 5.4. Pamiętacie problem z Garbage Collectorem włączonym przez funkcję gc_enable() z tego wpisu? Zniknął bezpowrotnie po aktualizacji PHP do wersji 5.4. Udało mi się znaleźć świetne repozytorium PPA, które ma najnowsze stabilne i sprawdzone wersje PHP prowadzone przez Ondřeja Surýego. Zawodowo zajmuje się on utrzymaniem wielu pakietów w Debianie i Ubuntu, poza tym znalazłem dużo ciepłych słów na temat jego repozytoriów w Internecie (takaże na ServerFaulcie i StackOverflow), więc chyba można mu wierzyć. Aby zainstalować z jego pomocą PHP 5.4 wystarczy wykonać kilka prostych poleceń:

sudo add-apt-repository ppa:ondrej/php5
sudo apt-get update
sudo apt-get upgrade

Jeśli w systemie brakuje Wam skryptu add-apt-repository, możecie go zainstalować następującym poleceniem:

sudo apt-get install python-software-properties

Jeśli pomimo wykonania wszystkich powyższych poleceń PHP nadal raportuje starszą wersję, pomaga wykonanie aktualizacji poleceniem dist-upgrade:

sudo apt-get dist-upgrade

Efekt? Zero problemów z wyrzucaniem skryptów do konsoli, segfaultami, tysiącem błędów w logach. Do tego wydajność zwiększona „z zegarkiem na ręku” o co najmniej 1/3. Sam nie mogłem uwierzyć w jaki sposób ten sam skrypt po zwykłym upgrade działa tak, jakby serwer był zasilany nie prądem, a paliwem rakietowym. :)

Druga sprawa: Fast-forward o jakieś 2 tygodnie: PHP 5.5 i Apache 2.4. Nie wiem, jak bardzo jesteście religijni, ale usłyszałem kiedyś takie bardzo prawdziwe (IMO) zdanie, że „kiedy Bóg chce kogoś ukarać, to mu odbiera rozum”. Łączy się to bezpośrednio z popularnym w naszej branży zdaniem „if it ain’t broke, don’t fix it”. Jak nietrudno się domyślić, chodzi w tym przypadku oczywiście o mnie.

Dzisiaj rano Ubuntu zaraportowało, że ma aktualizacje do zainstalowania. Aktualizacje w Linuksie (w opozycji do Windowsa*) są bardzo fajne, więc czemu nie – podałem hasło i wio. Dostałem jednak komunikat, że niektóre z nich nie dadzą się zainstalować, bo są niekompatybilne, niestandardowe, itp. (dokładnie nie pamiętam tego komunikatu). Jak się zapewne domyślacie, chodziło o nowe wersje pakietów z PPA Ondreja – w tym przypadku Apache 2.4 i PHP 5.5. Ucieszyłem się jak małe dziecko, że w końcu najnowsza stabilna wersja filarów stosu LAMP i oczywiście biegiem zainstalowałem wydając z konsoli kolejne polecenie dist-upgrade.

Wszystko pięknie i ładnie, odpalam moje lokalne projekty, śmiga aż miło (jak się okazało, był to przyjemny, ale… efekt placebo), ale Symfony2 raportuje w WebDebugToolbarze, że cały czas widzi PHP 5.4 (z aktualizacji powyżej). Apache podczas restartu pisze, że „widzi inny proces” nasłuchujący na porcie 80 i nic z nim nie będzie robiło, więc szybkie:

sudo killall -9 apache2
sudo /etc/init.d/apache2 restart

załatwia sprawę. Dalej niestety nie jest niestety ani odrobinę bardziej różowo. Odpalam projekty, „nie znaleziono serwera”. No to jedziemy:

sudo a2ensite vhosts.conf
sudo /etc/init.d/apache2 restart

Plik vhosts.conf to miejsce w którym trzymam konfigurację lokalnych projektów. Tu też trzeba pamiętać o tym, że Apache 2.4 wymaga rozszerzenia .conf w plikach konfiguracyjnych. Do tej pory nazywałem pliki VHostów tak jak domeny, które zawierały, więc większość lokalnych projektów była umieszczona w plikach w stylu projectDomain.dev. Od dzisiaj musi być to projectDomain.conf.

Klikam [F5], pokazuje mi się lista plików w katalogu /web Symfony2. Myślę sobie „ech…”, rozkazuję

sudo a2enmod rewrite
source /etc/apache2/envvars
apache2 -M | grep rewrite

ale nie dość, że Apache2 reaguje na to komunikatem „Module rewrite already enabled”, to jeszcze pokazuje ten moduł na liście. Sprawdzam .htaccess w projekcie, wszystko jest w porządku, to samo VHosty. Google, StackOverflow – jest trop, chodzi oczywiście o dyrektywę AllowOverride. Myślę sobie – ale dlaczego? Przecież w 2.2 wszystko działało dobrze, a teraz ktoś nagle zmienił zasady gry? Okazuje się, że tak, w pliku apache2.conf w domyślnym pakiecie Apache 2.4 znajduje się wyjaśnienie oraz „winne wszystkiemu” linijki:

# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.

<Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride None
  Require all granted
</Directory>

Zmieniamy None na All i na szczęście wszystko zaczyna działać. Jeśli macie projekty w innych katalogach, trzeba oczywiście skopiować cały blok i zmienić ścieżkę do projektów.

Trzecia sprawa: PHPMyAdmin. Okazuje się, że automatyczny alias localhost/phpmyadmin (prawdopodobnie aż do momentu, kiedy ktoś wyda poprawiony instalator / paczkę PMA) nie działa. Tutaj na szczęście sprawa jest prosta: w głównej konfiguracji Apache2 znajduje się jeszcze jeden blok do poprawienia:

<Directory /usr/share>
  AllowOverride None
  Require all granted
</Directory>

Zmieniamy None na All i zapisujemy plik. Następnie kopiujemy plik aliasu do katalogu vhostów, włączamy go do aktywnej konfiguracji i restartujemy serwer:

sudo cp /etc/apache2/conf.d/phpmyadmin.conf /etc/apache2/sites-available/phpmyadmin.conf
sudo a2ensite phpmyadmin.conf
sudo /etc/init.d/apache2 restart

Tym sposobem dobrnęliśmy do końca artykułu. Dziękuję Wam za poświęcony czas i do zobaczenia kolejnym razem. :)

* Kupiłem kilka lat temu komputer wujkowi. Nic specjalnego, Core 2 Duo, Radeon x1950 Pro, reszta na podobnym poziomie – słowem, komputer idealny do nauki ogólnej obsługi Internetu, programów, „normalnych” gier, itp. Ile razy do niego nie przyjeżdżam, zawsze jest to samo pytanie „Tomek, coś wyskakuje na ekranie, zobacz” – zazwyczaj aktualizacja antywirusa, jakiś raport systemowy, nic wielkiego. Ostatnio do tego „patrzenia” doszedł jeszcze jeden zarzut – „wolno działa”. Long story short – cała 50GB partycja systemowa miała kilkadziesiąt MB wolnego.

Jako, że już kiedyś naprawiałem komputer „załatwiony” w ten sposób (dziewczyna wszystko zapisywała na pulpicie, w pewnym momencie komputer po prostu przestał się uruchamiać – LiveCD Linuksa, kasowanie co większych plików – there, I fixed it), patrzę po kolei co ile zajmuje i dlaczego tak dużo. Kilkunastominutowe poszukiwania przyciągnęły moją uwagę do katalogu C:\Windows\WinSxS, który według dokumentacji trzyma pliki zapasowe lub tymczasowe używane podczas aktualizacji. W środku znajdowały się grube tysiące katalogów o nazwach /[amd|intel].[x32|x64].com.[you_name_it]/. Rozmiar? Prawie 20GB.

Szybkie pytanie do wujka Google, odpowiedź – możesz skasować, ale nie polecamy, bo „nie wiemy co się może stać” (parafrazuję, ale to był prawie cytat z MSDNu). Kazałem wujkowi od tej chwili nie klikać aktualizacji Windowsa, zwolniłem miejsca ile się dało usuwając różne niepotrzebne rzeczy i według relacji poziom wolnego miejsca trzyma się na bezpiecznym poziomie 3-4 GB. Jeśli ktoś ma „cynk” jak to można naprawić, będę wdzięczny.

BTW Zauważyłem, że większość wpisów na tym blogu rozpoczyna się od zwrotów „Jakiś czas temu”, „Ostatnio miałem problem”, itp. Czas podszkolić trochę warsztat, bo językowo chyba leży. Z drugiej strony, zawsze mogę liczyć na to, że będzie to mój znak rozpoznawczy, jak Grzegorz Marczak ze swoimi literówkami na Antywebie. Tomasz „Jakiś czas temu” Kowalczyk. :)