Niestety prawda jest taka, że niebieski słonik często zostaje przez użytkowników pomijany i przegrywa w starciu z delfinkiem ;P Nie ma się jednak co dziwić - większość oskryptowania dostępnego na rynku jest pisana pod MySQL'a, a instalując takie wyjątki jak popularne phpBB czy WikiMedia obsługujące również bez problemu Postgresa i tak odruchowo wybierany jest produkt Sunowski. Nie ma jednak co płakać - być może nadejdą lepsze dni dla PgSQL'a. Tymczasem zakończę swój wywód i przejdę szybko do sedna sprawy, dla której się tutaj dziś zebraliśmy ;)
Tak jak wspomniałem wykorzystanie bazy postgresowej na serwerze z cPanelem nie stanowi większego problemu - ot, klik, klik i nowa baza jest gotowa. Trochę inaczej to wygląda, gdy chcemy sami napisać aplikację korzystającą z systemu spod znaku słonia i musimy ją jakoś przetestować na localu zanim wypuścimy do sieci (no chyba, że stawiamy na całkowity hardcore i testujemy wszystko live: save, ftp, refresh :P Jeśli należysz do takiej grupy webmajstrów, to informuję iż źle trafiłeś). Wówczas koniecznością staje się (zupełnie jak w przypadku MySQL'a) instalacja serwera baz na lokalnym komputerze. Pojawia się tylko jedna mała przeszkoda - PgSQL nie wchodzi w skład XAMPPa, ani żadnego innego znanego Krasnala (przynajmniej ja nic o tym nie wiem) ;o Omgz! W takiej sytuacji pozostaje ręczna instalka. Już za chwilę będziecie wiedzieć jak to uczynić sprawnie i bezstresowo pod Fedorą.
Odpalamy terminal i logujemy się na roota. Instalujemy serwer baz, stosowny moduł dla PHP i phpPgAdmina:
yum install postgresql php-pgsql phpPgAdmin
Tip: Jeśli już wcześniej zainstalowano PHP (np zgodnie z moim tutorialem) i użyto do tego polecenia php\* to php-pgsql i phpPgAdmin powinny być już zainstalowane. Nie zaszkodzi jednak dodać ich do powyższego polecenia - najwyżej yum je sobie pominie.
Po zakończonej instalacji najpierw inicjalizujemy bazę, a następnie odpalamy serwer, logujemy się na użytkownika postgres i włączamy narzędzie psql:
service postgresql initdb
/etc/init.d/postgresql start
su postgres
psql
Tip: Przed logowaniem można sprawdzić w /etc/shadow czy użytkownik taki został utworzony podczas instalacji. Nazwa usera może aczkolwiek nie powinna różnić się od powyższej.
Tworzymy własnego użytkownika (login do bazy) - uwaga: operujemy tutaj zapytaniami sql'owymi, więc pamiętaj o średnikach na końcu linii!
create user sdr;
Ustawiamy hasło i nadajemy wszystkie uprawnienia, dzięki którym użytkownik otrzyma władzę absolutną nad serwerem :) Takie rzeczy to oczywiście tylko na localu - na serwerach dostępnych w sieci należy nadawać użytkownikom tylko takie uprawnienia jakich potrzebują (kwestia bezpieczeństwa). Podając hasło koniecznie umieść je w apostrofach:
alter user sdr password 'sR4tATa7A';
alter user sdr superuser;
alter user sdr createrole;
alter user sdr createdb;
alter user sdr createuser;
Na koniec tworzymy naszemu userowi domyślną bazę danych, do której będzie automatycznie logowany po uruchomieniu psql'a.
create database sdr owner sdr;
Wychodzimy z psql'a i wylogowujemy się z konta postgres:
\q
exit
Teraz czas na zmianę ustawień logowania. Jeśli pominiemy ten krok, mogą pojawić się problemy z logowaniem np do phpPgAdmina. Edytujemy stosowny plik konfiguracyjny serwera:
vim /var/lib/pgsql/data/pg_hba.conf
Tip: Przed wprowadzeniem zmian w pliku warto wykonać jego kopię zapasową.
Na końcu pliku znajduje się taka oto niby tabelka:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all ident sameuser
# IPv4 local connections:
host all all 127.0.0.1/32 ident sameuser
# IPv6 local connections:
host all all ::1/128 ident sameuser
Aby wszystko grało jak należy, musimy zmienić zawartość ostatniej kolumny (METHOD) z ident sameuser na md5. Podmieniamy wartości we wszystkich trzech wierszach, otrzymując:
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
Zapisujemy wszystkie zmiany z pliku i restartujemy serwer.
/etc/init.d/postgresql restart
Teraz można zalogować się do phpPgAdmina.
Na zakończenie dzisiejszego artykułu wspomnę jeszcze tylko o jednej (istotnej m.in. dla użytkowników MediaWiki) sprawie związanej z instalacją różnego rodzaju oskryptowania wykorzystującego bazy PostgreSQL. Czasami może występować błąd w instalacji i skrypt może wypluć dziwny dla niektórych błąd związany z tsearch2 (skrypt wymaga zaimplementowanej funkcjonalności pełnego indeksowania tekstu). Ja takowy problem napotkałem w czasie instalacji właśnie MediaWiki na localu. Należy wówczas odpalić terminal, przejść do katalogu /usr/share/pgsql/contrib i upewnić się czy istnieje tam plik tsearch2.sql (jeśli nie, trzeba dociągnąć yumem pakiet postgres-[wersja]-contrib - gdzie [wersja] to oczywiście nasza wersja Postgresa). Następnie logujemy się na swojego usera i ładujemy wspomniany plik do bazy, w której chcemy zainstalować MediaWiki:
psql [nazwa_bazy_dla_wiki] < tsearch2.sql
Psql poprosi nas o hasło. Wpisujemy je i ponawiamy próbę instalacji.
Kolejne kilka postów poświęcę na zabawy z domenami. Następnym razem zobaczymy jak tanio zarejestrować nową domenę i gdzie ją wydelegować, aby... wykorzystać do granic możliwości. Czekajcie cierpliwie ;D
Zauważyłeś błąd w artykule? Coś nie działa? Zostaw swoje uwagi w komentarzach.
4 komentarze:
MySQL jest płatne tylko w przypadku, gdy udostępniasz MySQL ze swoim programem, zresztą więcej poczytasz tutaj: http://blogs.ittoolbox.com/webdesign/php/archives/the-mysql-license-8922
Osobiście używam MySQLa, bo teoretycznie jest szybszy, prostszy i popularniejszy (co świadczy o nim samym). Zresztą więcej info tutaj: http://articles.techrepublic.com.com/5100-22-1050671.html
Hmm, ten test pochodzi sprzed sześciu lat, więc wiesz... dużo się mogło od tej pory zmienić ;p
A co do licencji to ja wiem, że niby MySQL jest darmowy, gdy nie dołączasz go (serwera) do zamkniętego projektu. Wiem też, że PHP ma tam jakąś swoją licencję od MySQL'a. Nie chciałem się we wstępie do posta rozdrabiać, bo to tutek, a nie miejsce do wyrażania opinii. No, ale skoro zacząłeś już drążyć temat to powiem, że miałem pewne wątpliwości co do wykorzystania bibliotek klienckich MySQL'a w PHP w przypadku, gdy źródła skryptu są zaszyfrowane jakimś encoderem (np IonCube, Zend Encoder, etc). Czytałem wiele sprzecznych komentarzy na ten temat i w sumie nigdy nie znalazłem jednoznacznej odpowiedzi. Co najciekawsze: nawet na forum MySQL'a developerzy wypytywani o takie sytuacje nie wiedzieli co z tym począć - ciągle padały tylko odpowiedzi, że (uwaga!) sprawę mogą rozstrzygnąć jedynie prawnicy xD Lol. Więc jak powiedziałem, sam nie wiem co dalej z tym fantem. Ale to tylko taka mała dygresja do poradnika - dyskusja na inną okazję ;p
Jest sprzed sześciu lat, ale z tego co wiem, płatna licencja MySQL'a powstała w 2001 roku i od tej pory się nie zmieniła. :o A zresztą, jeden ch**, jakiej bazy się używa do tworzenia stron. Zastanawiałbyś się dopiero przy tworzeniu większych aplikacji z 8 000 000 rekordów w tabeli komentarze. :>
No właśnie, ja tak przyszłościowo myślę już ;) Dobra, dajmy se siana z tymi licencjami.
Prześlij komentarz