Menu Zamknij

OSX i managery oprogramowania – czyli (niezbyt) krótka historia o tym jak musiałem się przeprosić z MacPorts

Mniej więcej od 2006 roku pracuję na Makach. Zaczynałem od Maca mini, potem iMac, a potem już różne Macbooki. Przez te wszystkie lata nabrałem przekonania (popartego doświadczeniami), że komputery Apple dużo lepiej nadają się do programowania i tworzenia stron www niż PC. Powodem jest oczywiście architektura, oparta na systemach Unixowych. Tak, wiem, Linux też się nadaje. Nie przeczę. No ale na Linuxie trochę ciężko o Photoshopa… Ale nie o tym…

Apple w swojej łaskawości pewne przydatne funkcje systemu daje nam w pakiecie, a mówię tu np. o serwerze www Apache i wbudowanemu PHP. No i wszystko jest ok, dopóki nie mamy potrzeby by dodać jakieś brakujące rozszerzenie do PHP, np. drivery PDO do komunikacji z bazą danych PostgreSQL. Bo tak się składa, że w wersji wbudowanej mamy drivery do MySQL, ale o Postgresie już zapomniano. Generalnie schody zaczynają się w momencie, gdy chcemy coś doinstalować i przekompilować. Tego producent już nie wspiera – masz biniarki i się ciesz…

Na szczęście rynek nie znosi próżni i pojawiły się zewnętrzne managery oprogramowania – czyli programy pozwalające doinstalować, skompilować i uruchomić oprogramowanie, o którym Apple jakoś zapomniało. Jest to szczególnie przydatne przy pracy zarówno front- jak i backendowca.

Takich managerów oprogramowania jest kilka i tu po więcej szczegółów odsyłam do stosownego artykułu: https://www.slant.co/topics/511/~best-mac-package-managers

Ja chciałbym skupić się na 2 – chyba najpopularniejszych: Homebrew i MacPorts.

Przez kilka lat używałem MacPorts, później skusił mnie Homebrew. Był nowszy, wydawał się lepszy (i w zasadzie jest, bo lepiej integruje się z OSX i instaluje mniej zależności), ale po ostatnich aktualizacjach wycofano z Homebrew wsparcie dla części starszych pakietów oprogramowania – np. PDO mysql dla PHP 5.6 i kilka innych pakietów dla tej wersji PHP.

Ja wiem – PHP 5 to już historia mamy wersję 7. I dlaczego w ogóle piszę o PHP, skoro to jest blog poświęcony frontendowi?

Życie programisty frontend to nie tylko najnowsze frameworki i HDD (Hype Driven Development), ale też wspieranie kodu legacy – rozwijanie czegoś w starszych, ale wciąż pracujących projektach. Czasem zachodzi potrzeba by uruchomić jakiś system lokalnie, gdzie niektóre zależności są już raczej historyczne. Koledzy ostrzegali – nie aktualizuj Homebrew bo wywalili masę starszych pakietów – no ale przesiadka na nowego kompa wymusiła postawienie całego środowiska od nowa. No i tu właśnie postanowiłem się przeprosić ze starymi dobrymi MacPortami.

Tu kończy się część fabularna, a zaczyna się opis instalacji Apache 2.4 + PHP 5.6 – trochę jako ciekawostka, a trochę jako ściąga na przyszłość 🙂


Zacznijmy więc od samej instalacji MacPorts – wchodzimy na stronę https://www.macports.org/install.php i wybieramy wersję dla naszego systemu – w moim wypadku dla High Sierra. Ściągamy biniarkę i instalujemy – tu nie ma żadnej filozofii.

Po zakończonej instalacji mamy do dyspozycji nowy program dostępny z linii poleceń terminala – nazywa się on po prostu port.

Zobaczmy czy działa – sprawdźmy jego wersję:

port -v

W odpowiedzi dostałem:

MacPorts 2.5.0

Jest dobrze – porty działają i odpowiadają.

Raz na jakiś czas warto je zaktualizować – służy do tego polecenie:

sudo port -v selfupdate

Zdecydowanie warto zapoznać się z dokumentacją dostępną na stronie: https://guide.macports.org

W tej chwili mnie interesują 2 podstawowe polecenia:

port search <nazwa_pakietu>
sudo port install <nazwa_pakietu>

O ile wyszukiwanie pakietów można uruchomić na prawach użytkownika, o tyle instalowanie wymaga praw administratora. Dzieje się tak dlatego, że MacPorts domyślnie instaluje oprogramowanie i katalogu poza katalogiem domowym użytkownika:

/opt/local

Zainstalujmy więc trochę oprogramowania – w moim wypadku będą to następujące pakiety:

  • apache2 (serwer www w wersji 2.4)
  • php56 (główny pakiet PHP)
  • php56-apache2handler (moduł PHP do wpięcia w Apache)
  • php56-iconv (moduł PHP do konwersji kodowania stringów)
  • php56-intl (moduł do internacjonalizacji)
  • php56-mcrypt (moduł do szyfrowania/deszyfrowania)
  • php56-mysql (driver do bazy danych MySQL)
  • php56-postgresql (driver do bazy danych PostgreSQL)
  • php56-xdebug (moduł do debugowania w IDE)

Po instalacji możemy sprawdzić listę zainstalowanych pakietów za pomocą polecenia:

port installed

Na wyświetlonej liście pakietów jest oczywiście dużo więcej, bo instalowane przez nas pakiety mają własne zależności 🙂

Po udanej instalacji dostajemy na twarz trochę informacji odnośnie ścieżek instalacji, które warto sobie zapisać:

The install paths have been changed to no longer violate the MacPorts mtree:

1. The binaries are now under /opt/local/sbin/
(rather than under /opt/local/apache2/bin/)

2. The configure files are now under
(rather than under /opt/local/apache2/conf/)

3. The modules are now under /opt/local/lib/apache2/modules/
(rather than under /opt/local/apache2/modules/)

4. The web root is now located under /opt/local/www/apache2/html/
(rather than under /opt/local/apache2/htdocs/)

5. The cgi-bin is now located under /opt/local/www/apache2/cgi-bin/
(rather than under /opt/local/apache2/cgi-bin/)

6. The logs are now located under /opt/local/var/log/apache2/
(rather than under /opt/local/apache2/logs/)

7. The manual is now located under /opt/local/www/apache2/manual/
(rather than under /opt/local/apache2/manual/)

8. The manual (man) pages are still at /opt/local/share/apache2/man/

You can move your htdocs and cgi-bin to the new locations, or edit /opt/local/etc/apache2/httpd.conf to point at the old locations.

Jeśli chcemy żeby Apache startował razem z systemem, to o tym też mamy informację:

A startup item has been generated that will aid in starting apache2 with launchd. It is disabled by default. Execute the following command to start it, and to cause it to launch at startup:

sudo port load apache2

Ja osobiście wolę serwer startować ręcznie, bo nie zawsze go potrzebuję (czasem jednak się pisze w czymś nowszym typu Angular 6 czy Vue), więc tu kilka przydatnych komend:

sudo apachectl start
sudo apachectl stop
sudo apachectl restart

PHP też nas raczy swoim komunikatem:

To customize php56, copy /opt/local/etc/php56/php.ini-development (if this is a development server) or /opt/local/etc/php56/php.ini-production (if this is a production server) to /opt/local/etc/php56/php.ini and then make changes.

Generalnie chodzi mu o to, że jeśli chcemy zrobić jakieś modyfikacje w konfiguracji PHP, to warto by sobie zrobić własny plik php.ini na podstawie któregoś z przykładowych. W tym przypadku wykorzystajmy mniej restrykcyjny plik dla developmentu:

cd /opt/local/etc/php56/
cp php.ini-development php.ini

Możemy też od razu włączyć moduł PHP w Apache:

To enable php56-apache2handler, run:

cd /opt/local/lib/apache2/modules
sudo /opt/local/bin/apxs -a -e -n php5 mod_php56.so

No dobra, wstępną konfigurację mamy za sobą, czas na delikatny tuning:

  • w php.ini warto ustawić kilka opcji:
    • memory_limit = 128M – tu dałbym więcej jeśli nasz PHP ma robić coś cięższego
    • error_reporting = E_ALL – tu raczej E_ALL & ~E_DEPRECATED & ~E_STRICT żeby za dużo PHP nie komunikował 🙂
    • date.timezone = 'Europe/Warsaw’ – tu warto ustawić właśnie taką wartość, unikniemy komunikatów błędów z PHP…
  • w katalogu /opt/local/etc/apache2 znajdziemy plik httpd.conf, w nim warto ustawić:
    • LoadModule rewrite_module – rewrite przydaje się w wielu projektach więc odkomentowujemy
    • LoadModule php5_module – to już powinno być aktywne…
    • ServerAdmin – tu warto wpisać swój email
    • ServerName – tu warto coś podać, żeby Apache nie rzucał info o braku nazwy za każdym startem, np. mac.local
    • DirectoryIndex index.html index.php – tu dopisujemy właśnie index.php, żeby Apache rozpoznał ten plik jako startowy
    • Dodajemy też rozpoznawanie plików PHP przez Apache:
      <FilesMatch "\.php$">
      SetHandler application/x-httpd-php
      </FilesMatch>
    • Include etc/apache2/extra/httpd-vhosts.conf – tą opcję warto odkomentować by móc definiować własne wirtualne hosty – bardzo przydatne 🙂
  • w katalogu /opt/local/etc/apache2/extra znajdziemy plik httpd-vhosts.conf.orig – kopiujemy go jako httpd-vhosts.conf i w nim dodajemy jakiegoś hosta, np.
    <VirtualHost *:80>
        DocumentRoot "/Users/mwalczak/Sites/sklep/"
        ServerName sklep.local
        <Directory "/Users/mwalczak/Sites/sklep">
            Options Indexes MultiViews FollowSymLinks
            AllowOverride All
            Order allow,deny
            Allow from all
        </Directory>
    </VirtualHost>

Dodając wirtualnego hosta pod lokalną domeną (np. sklep.local) warto by było dodać tą domenę do pliku /etc/hosts

127.0.0.1 sklep.local

Po takiej konfiguracji czas wystartować nasz serwer:

sudo apachectl start

Jeśli wszystko poszło dobrze to efekt nie będzie zbyt spektakularny – Apache startuje sobie w tle i nic więcej się nie dzieje. Warto więc upewnić się, że co tak naprawdę się uruchamia – Apache wbudowany fabrycznie czy ten nowy z MacPorts. Pomocne będzie tu polecenie:

which apachectl

Użycie go wyświetli (a przynajmniej powinno):

/opt/local/sbin/apachectl

Polecenie to wskazuje ścieżkę do domyślnie uruchamianego programu. O ile w przypadku Apache ścieżka jest prawidłowa, o tyle polecenie:

which php

wyświetla:

/usr/bin/php

a polecenie

php -v

zwraca wynik:

PHP 7.1.14 (cli) (built: Feb 7 2018 18:33:30) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies

Widzimy więc, że PHP uruchamiany z linii poleceń odwołuje się do wbudowanego do OSX PHP 7.

Dzieje się tak, ponieważ nasz PHP 5.6 z MacPorts dodał biniarkę w katalogu /opt/local/bin pod nazwą php56. Aby to rozwiązań utwórzmy dowiązanie symboliczne do tego pliku:

cd /opt/local/bin
sudo ln -s php56 php

Teraz (najlepiej po restarcie Terminala) pod nazwą php mamy odniesienie do php56.

Skąd jednak system wie którą biniarkę ma użyć? Decyduje o tym mechanizm PATH. W tej zmiennej globalnej znajdują się ścieżki przeszukiwania systemu przy próbie uruchomienia jakiegoś programu bez podania jego dokładnej ścieżki.

Zobaczmy jak wygląda zawartość tej zmiennej:

echo $PATH

W moim przypadku zwraca:

/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Jak widać poszczególne ścieżki są rozdzielone znakiem dwukropka, a kolejność przeszukiwania jest następująca: od lewej do prawej – czyli w wypadku wydania polecenia php, najpierw jest przeszukiwany katalog: /opt/local/bin, później /opt/local/sbin itd…

Jeśli Twoje ścieżki wyglądają inaczej, zawsze można je zmienić, np. dodając taki wpis w pliku .bash_profile w katalogu domowym:

export PATH="/opt/local/bin:/opt/local/sbin:$PATH"

Tak wygląda przykład instalacji Apache 2 i PHP 5.6 za pomocą MacPorts. Oczywiście to zaledwie wycinek tematu, ot zaledwie wystarczający do uruchomienia serwera i lokalnej kopii jakiegoś starszego projektu. Szczegóły dotyczące konfiguracji mogą się różnić jeśli projekt posiada jakieś bardziej złożone zależności.

Na pewno jednak warto zapoznać się z dokumentacją MacPorts – znajdziesz tam instrukcję jak np. odinstalować zbędne/niechciane pakiety, a także jak je aktualizować.

Jeśli uważasz, że ten artykuł jakoś Ci się przydał lub masz jakieś uwagi którymi chciałbyś się podzielić, to sekcja komentarzy jest dla Ciebie. Zapraszam!

2 komentarze

  1. Sebastian

    Problem polega na tym że opisane przez ciebie rozwiazanie nijak nie chce działać na El Capitan. 2.4 + php 7.3.5 nie chce mi nawet załadować pliku z funkcja phpinfo() już nie mówiąc o tym iż w 2.2 można było mieć wsparcie dla katalogów użytkowików bez tyldy domyślnie a teraz domyślnie robi tyldę.

    • Maciek

      Hej! Ciężko mi się do tego odnieść nie znając szczegółów błędów czy konfiguracji – ja takiego lub podobnego settingu używam przez ostatnie 6-7 wersji OSXa. Najpierw używałem głównie MacPorts, potem przez jakiś czas Homebrew, a potem znów MacPorts (bo z Homebrew poznikały starsze pakiety).

      Tak naprawdę i tak docelowym rozwiązaniem są kontenery Dockerowe – lub podobne rozwiązanie – bo środowisko lokalne ma tą wadę, że jak masz kilka projektów które muszą działać jednocześnie (bo się komunikują między sobą), a mają różne wymagania co do wersji PHP, to ciężko to zrealizować na globalnie zainstalowanym Apache’u i PHP.

Skomentuj Maciek Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *