Podstawowa konfiguracja

Tworzenie nowej bazy danych

Jeżeli nasz serwer już działa naprawdę powinniśmy utworzyć nową bazę danych, gdyż nie powinno się pracować żadnej z defaultowych template0/1. Możemy to zrobić na dwa sposoby, za pomocą oddzielnego narzędzia, oraz za pomocą polecenia SQL. Opiszę tutaj tylko tą drugą metodę, gdyż jest ona bardziej uniwersalna ( można to zrobić również zdalnie ). Najpierw musimy połączyć się z serwerem. Do tego użyjemy narzędzie dostarczanego wraz z bazą, a mianowicie psql. Najpierw musimy zalogować się jako użytkownik-właściciel bazy. Potem musimy połączyć się z bazą danych. Jako, że PostgreSQL wymaga podania bazy danych, do jakiej chcemy się połączyć, a my takowej jeszcze nie posiadamy połączymy się z bazą template1. ?eby tego dokonać musimy wykonać polecenie psql -d template1. Jako, że domyślnym ustawieniem bazy jest wpuszanie wszystkich z localhost, więc od razu wejdziemy do interfejsu programu bez podawania hasła. Bazę danych stworzyć możemy komendą:

"

CREATE DATABASE nazwa;

"

Jeżeli chcemy możemy podać więcej szczegółów na temat bazy, jak właściciel, strona kodowa czy baza, z której tworzona ma dziedziczyć. Najlepiej jest stworzyć bazę o imieniu użytkownika jakim najczęściej będziemy się łączyć z bazą danych, gdyż wtedy nie będziemy musieli podawać jawnie nazwy bazy danych przy połączeniach.

Konfigurowanie dostępu do bazy

Jeżeli już mamy działający serwer oraz stworzoną bazę danych to teraz przyszedł właściwy moment na ustawienie odpowiednich reguł dostępu. Jest to zadanie niezwykle ważne, ponieważ PostgreSQL ustawia domyślnie bardzo swawolne reguły dostępu. Najpierw zaczniemy od ustawienie hasła administratorowi ( którego, żebyście się nie zdziwili, wcale nie znacie - spróbujcie się dostać do psql'a z opcją -W ). Do robienia tego służy specjalne polecenie SQL ALTER USER. Najpierw łączymy się jako postgres ( administrator bazy danych ) do psql'a poleceniem psql -d nazwa, gdzie nazwa to nazwa bazy jaką stworzyliśmy w poprzednim podpunkcie. Teraz musimy wykonać następujące zapytanie:

" "

W powyższym zapytaniu postgres to nazwa użytkownika administratora, a 'new_password' to hasło jakie chcemy mu nadać, oba te elementy można zmieniać. Teraz należałoby jeszcze dodać nowego użytkownika, bez uprawnień administratora, aby praca była bezpieczniejsza. Wykonamy to za pomocą następującego zapytania ( oczywiście musimy to zrobić jako administrator ):

" "

W powyższym zapytaniu nazwa to nazwa użytkownika do stworzenia, a 'password' to hasło jakie chcemy mu nadać. Teraz już możemy się łączyć do bazy jako użytkownik, którego przed chwilą stworzyliśmy.

Ale co jest? Możemy się łączyć z baza danych nie podając hasła! Odpowiada za to plik $PG_DATA/pg_hba.conf. Domyślnie wygląda on w ten sposób ( część znacząca - czyli ostatnie parę linijek ):

Jest to główna część odpowiadająca za dostęp do bazy. Jak widać wszystko składa się z 6 kolumn ( bądź 4, jeżeli definiujemy prawa na połączeniach lokalnych ). Wszystkie kolumny są oddzielone od siebie białymi znakami ( spacja lub znak tabulacji ). Pierwsza kolumna oznacza, jaki rodzaj połączeń definiujemy. Jeżeli ma wartość local, oznacza to, że definiujemy połączenie lokalne przez UNIKsowe gniazda, jeżeli natomiast ma wartość host, oznacza to, że definiujemy połączenie przez protokół tcp/ip. Jest jeszcze jedna możliwość ( dla bardziej zaawansowanych zastosowań ), a mianowicie hostssl, która oznacza, że połączenia z tego hosta muszą być kodowane. Druga i trzecia kolumna oznaczają odpowiednio nazwę bazy danych oraz użytkownika, dla którego definiujemy połączenie. Czwarta i piąta kolumna ( ważne tylko jeżeli definiujemy połączenie typu host lub hostssl ) oznaczają adres IP oraz maskę z jakich połączenia mają przychodzić połączenia. Ostatnia kolumna ( najważniejsza) mówi, w jaki sposób użytkownik ma być autoryzowany. Główne i najczęściej używane opcje to trust, password oraz md5. Pierwsza oznacza, że w ogóle nie trzeba podawać hasła, druga mówi o konieczności podania hasła w postaci text/plain a trzecie, że powinno ono być zakodowane przez md5. W sumie dobrym rozwiązaniem jest ustawienie tego pliku w taki sposób:

Musimy jeszcze zrestartować bazę, wykonamy to poleceniem pg_ctl -D $PG_DATA restart, gdzie oczywiście musimy zmienić ścieżkę dostępu na tą, którą podaliśmy w naszym systemie. Teraz już możemy się zalogować do bazy jako ktokolwiek. Powinniśmy zobaczyć ładną zachętę do wpisania hasła.

Inne opcje

Głównym plikiem konfiguracyjnym bazy jest plik $PG_DATA/postgresql.conf. Są tam przechowywane praktycznie wszystkie dane temat zachowania naszej bazy. Bardzo dobry opis dostępnych tutaj opcji znajduje się na stronie http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html. Nie będę tutaj tworzył aż tak dokładnego opisu, gdyż nie na tym istota tego artykułu polega, dla osób stawiających jednak komercyjny serwer polecam przyjrzeć się tamtej stronie.

Opcje połączeń

Opcje tutaj opisane służą do regulowania możliwości/parametrów połączenia się z bazą. Jest tutaj stosunkowo niewiele, aczkolwiek stosunkowo ważnych opcji.

tcpip_socket

Opcja może mieć wartość true albo false. Mówi, czy powinna być możliwość dostępu do bazy z sieci ( według reguł zdefinowanych w sekcji 4.2 ), czy też nie. Jeżeli możliwe są tylko połączenia przez sockety lokalne.

max_connections

Opcja okresla maksymalną liczbę połączeń, jakie mogą być nawiązane z bazą w jednym czasie.

superuser_reserver_connections

Opcja określa, ile połączeń powinno pozostać wolnych dla superużytkownika ( administratora ). Oznacza ona, że połączeń dla zwykłych użytkowników jest liczba zdefiniowana powyżej minus liczba połączeń zarezerwowanych dla superużytkownika. W praktyce przy większości wystarcza jedno.

port

Oznacza, na jakim porcie ma nasłuchiwać baza. Jeżeli tcpip_socket jest ustawiony na false to opcja jest ignorowana.

authentication_timeout

Określa liczbę sekund ( 1 - 600 ), jaka może maksymalnie upłynąć gdy baza oczekuje na autoryzacje nowo nawiązanego połączenia.

Są to najważniejsze opcje w tej dziedzinie. Wraz z dobrym ustawieniem opcji omawianych w sekcji 4.2 oraz dobrym ustawieniem uprawnień w samej bazie ( nie omawiane w tym artykule ) można osiągnąć naprawdę wysoki poziom bezpieczeństwa.

Opcje wewnętrzne

Opcje logowania