PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Erste Schritte mit PostgreSQL 11 auf Ubuntu 18.04

Obwohl PostgreSQL ein modernes und vielseitiges RDBMS ist, ist es nicht einfach, es einzurichten und loszulegen, wenn Sie eine Anwendung entwickeln möchten. Lesen Sie weiter, um zu erfahren, wie Sie mit der neuesten Version von PostgreSQL in der LTS-Version von beginnen können Ubuntu.

Installation

Ubuntu 18.04 wird mit PostgreSQL 10 geliefert, aber wir können stattdessen das vom PostgreSQL-Team gehostete APT-Repository verwenden, um die neueste Version, PostgreSQL 11, zu installieren.

Sie können das Repository mit diesen Befehlen einrichten:

# add the repository
sudo tee /etc/apt/sources.list.d/pgdg.list <<END
deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main
END

# get the signing key and import it
wget https://www.postgresql.org/media/keys/ACCC4CF8.asc
sudo apt-key add ACCC4CF8.asc

# fetch the metadata from the new repo
sudo apt-get update

Installieren Sie dann die Software selbst mit:

sudo apt-get install postgresql-11

Die Installation macht ein paar Dinge:

  • Es installiert den PostgreSQL-Server, Dienstprogramme und einen Befehlszeilen-Client namens psql .
  • Es erstellt einen Linux-Systembenutzer namens postgres . Alle Datendateien gehören diesem Benutzer, und alle Prozesse werden unter diesem Benutzer ausgeführt.
  • Es erstellt eine Datenbank, auch postgres genannt .
  • Es erstellt einen PostgreSQL-Benutzer (nicht der Benutzer des Linux-Systems), auch postgres genannt .

Sie können sehen, dass dies langsam verwirrend wird!

Datenbank-Cluster

Ihr neu installierter PostgreSQL-Server besteht aus einer Reihe von Prozessen, die einen sogenannten „Datenbank-Cluster“ verwalten. Sie können die Prozesse hier sehen:

alice@devbox:~$ ps axfww | grep postgres
 4737 ?        S      0:00 /usr/lib/postgresql/11/bin/postgres -D /var/lib/postgresql/11/main -c config_file=/etc/postgresql/11/main/postgresql.conf
 4749 ?        Ss     0:00  \_ postgres: 11/main: checkpointer
 4750 ?        Ss     0:00  \_ postgres: 11/main: background writer
 4751 ?        Ss     0:00  \_ postgres: 11/main: walwriter
 4752 ?        Ss     0:00  \_ postgres: 11/main: autovacuum launcher
 4753 ?        Ss     0:00  \_ postgres: 11/main: stats collector
 4754 ?        Ss     0:00  \_ postgres: 11/main: logical replication launcher  

Der Hauptprozess (hier mit PID 4737) ist der Hauptprozess, der die untergeordneten Prozesse weiter hervorbringt – dies wird üblicherweise als „Postmaster“-Prozess bezeichnet.

Die Verwendung des Begriffs „Cluster“ durch PostgreSQL ist älter als der moderne DistributedClustering-Jargon – hier bedeutet es nur eine Reihe von Datenbanken, die auf einem einzigen Computer von einem einzigen Postmaster verwaltet werden. Lesen Sie hier mehr über Cluster.

Ein Cluster enthält unter anderem Datenbanken (vorerst haben wir nur eine, „postgres“) und PostgreSQL-Benutzer (vorerst wieder nur eine, auch „postgres“ genannt). Damit Sie es wissen, ist der Cluster mit einer ganzen Reihe von Datendateien verknüpft, die sich alle in einem einzigen Verzeichnis befinden – in diesem Fall unter /var/lib/postgresql/11/main . Haben Sie diesen Pfad oben in der Postmaster-Befehlszeile bemerkt?

Wenn Ihre App oder psql eine Verbindung zu Postgres herstellt, muss dies im Kontext eines PostgreSQL-Benutzers erfolgen. Es gibt immer ein PostgreSQL-Benutzer, der einer Verbindung zugeordnet ist. Aber wie Sie vielleicht schon erraten haben, kann ein PostgreSQL-Benutzer einem Systembenutzer entsprechen oder auch nicht.

Systembenutzer und PostgreSQL-Benutzer

PostgreSQL-Benutzer können mit SQL-Befehlen wie CREATE ROLE oder gebündelten Tools wie createdb.

erstellt werden

Wenn eine Anwendung versucht, eine Verbindung zu Postgres herzustellen, muss sie einen PostgreSQL-Benutzernamen angeben. Sehen wir uns an, was passiert, wenn Sie einen PostgreSQL-Client wie psql starten:

alice@devbox:~$ psql
psql: FATAL:  role "alice" does not exist

Hier ist „alice“ Ihr Linux-Systembenutzername. psql übernimmt diesen Namen und verwendet ihn als Postgres-Benutzernamen. Eine Rolle (Rollen sind ein generischer Name für „Benutzer“ oder „Gruppe“, BTW) mit diesem Namen existiert nicht, worüber sich Postgres beschwert.

Wir wissen, dass es eine Rolle mit dem Namen „postgres“ gibt, also versuchen wir das. Wir können den „-U“-Parameter von psql verwenden, um den Benutzernamen anzugeben:

alice@devbox:~$ psql -U postgres
psql: FATAL:  Peer authentication failed for user "postgres"

OK, wir kommen näher – die Rolle/der Benutzer „postgres“ existiert, aber die „Peerauthentifizierung“ ist fehlgeschlagen. Was ist diese „Peer-Authentifizierung“?

Peer- und Passwortauthentifizierung

PostgreSQL-Clients wie psql oder Ihre App können sich über einen dieser IPC-Mechanismen mit dem PostgreSQL-Server verbinden:

  • Unix-Domain-Sockets
  • TCP-Sockets

Im Gegensatz zu TCP-Sockets bieten Unix-Domain-Sockets die Möglichkeit, die Systembenutzer-ID der Clientverbindung zu validieren. Der Postgres-Server kann eine eingehende Verbindung über einen Unix-Domain-Socket untersuchen und die Systembenutzer-ID des Clients ermitteln und dann entscheiden, ob er ihm Zugriff gewährt oder nicht.

Standardmäßig lauscht Ihr Server nur auf Verbindungen über Unix-Domain-Sockets und nicht auf TCP/IP.

Mal sehen, was passiert, wenn wir versuchen, psql als Systembenutzer zu starten postgres:

alice@devbox:~$ sudo -u postgres psql
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
Type "help" for help.

postgres=#

Das hat funktioniert! (Verwenden Sie „\q“, „\quit“ oder ^D zum Beenden von psql, BTW.)

Wenn bei der Peer-Authentifizierung die Client-Verbindung über einen Unix-Domainsocket hergestellt wird und der Client-Prozess denselben Systembenutzernamen hat wie der PostgreSQL-Benutzer, mit dem er versucht, eine Verbindung herzustellen, dann wird die Authentifizierung als erfolgreich betrachtet.

PostgreSQL-Benutzern kann optional auch ein Passwort zugewiesen werden, und Sie können PostgreSQL bitten, eingehende Verbindungen mit dem Passwort zu validieren. Aber wie? Das ist das nächste Puzzleteil.

pg_hba.conf

Jetzt ist es an der Zeit, die (un)berühmte Konfigurationsdatei pg_hba.conf zu öffnen, die sich unter /etc/postgresql/11/main/pg_hba.conf befindet :

sudo vim /etc/postgresql/11/main/pg_hba.conf

HBA steht für hostbasierte Authentifizierung. Grundsätzlich wird diese Datei verwendet, um zu steuern, wie PostgreSQL-Benutzer authentifiziert werden. Diese Datei ist wahrscheinlich der nicht intuitivste Teil der PostgreSQL-Lernkurve. Die Referenzdokumentation ist hier, Sie sollten sie später lesen.

Die erste Zeile (ohne Kommentar) lautet hier:

local all postgres peer

die Postgres anweist, „lokale“ (Unix-Domain) Verbindungen zu „allen“ Datenbanken zu akzeptieren und sich als Benutzer „postgres“ mit „Peer“-Authentifizierung zu authentifizieren. Aus diesem Grund funktioniert die Verbindung als Systembenutzer „postgres“ sofort.

Die Reihenfolge der Zeilen in dieser Datei ist wichtig, die erste übereinstimmende Zeile gewinnt. Sehen wir uns eine andere Zeile an:

host all all 127.0.0.1/32 md5

Diese Zeile erlaubt „allen“ Benutzern, sich über TCP/IP („host“) vom localhost („127.0.0.1/32“) bei „allen“ Datenbanken anzumelden, wenn ihnen die Passwortauthentifizierung mit der „md5“-Methode gelingt.

Es gibt mehr Passwort-Authentifizierungsmethoden (md5, scram-sha-256, gss, ldap, …), als wir behandeln können, also kehren wir zu einfacheren Beispielen zurück.

Aber zuerst müssen wir sicherstellen, dass PostgreSQL auch TCP/IP-Verbindungen akzeptiert. Dafür müssen wir die Hauptkonfigurationsdatei bearbeiten.

postgresql.conf

Die Datei /etc/postgresql/11/main/postgresql.conf ist die Hauptkonfigurationsdatei für Ihren PostgreSQL-Cluster. Diese Datei enthält viel von Einstellungen, und zu verstehen, was all diese bedeuten, ist überhaupt keine leichte Aufgabe. Sehen wir uns zunächst die allererste Einstellung an:

#listen_addresses = 'localhost'

Diese Zeile ist standardmäßig auskommentiert, kommentieren wir sie aus, damit sie wie folgt lautet:

listen_addresses = 'localhost'

Dadurch lauscht PostgreSQL auf eingehende TCP/IP-Verbindungen auf localhost, Port 5432 (Standard). Speichern Sie die Änderungen (dazu müssen Sie „root“ sein) und starten Sie den Postgres-Server neu, damit die Änderungen wirksam werden:

sudo systemctl restart postgresql

(Beachten Sie, dass Sie für die meisten Einstellungsänderungen nur „neu laden“ müssen, nicht „neu starten“, aber dies erfordert einen „Neustart“).

Jetzt können wir sehen, dass Postgres auf Port 5432 lauscht, der an 127.0.0.1 gebunden ist:

alice@devbox:~$ sudo netstat -tnlp | grep 5432
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      8408/postgres

Jetzt richten wir einen neuen Benutzer und eine neue Datenbank für die Verwendung durch eine App ein.

App-Setup

Verbinden wir uns als Superuser „postgres“, um die Änderungen vorzunehmen:

alice@devbox:~$ sudo -u postgres psql
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
Type "help" for help.

postgres=# create user myapp_user password 's3cr3t';
CREATE ROLE
postgres=# create database myapp owner myapp_user;
CREATE DATABASE
postgres=#

Wir haben jetzt eine Datenbank namens myapp erstellt und einen Benutzer namens myapp_user , mit dem Passwort s3cr3t . Die Datenbank ist leer und gehört dem Benutzermyapp_user , was bedeutet, dass Sie sich als myapp_user verbinden Der Client kann die meisten DDL/DML-Befehle ausführen.

Verbinden wir uns jetzt als dieser App-Benutzer mit der App-Datenbank:

alice@devbox:~$ psql -h 127.0.0.1 -d myapp -U myapp_user
Password for user myapp_user:
psql (11.0 (Ubuntu 11.0-1.pgdg18.04+2))
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

myapp=>

Es funktionierte! Sie sind jetzt mit „myapp“ (siehe Eingabeaufforderung) verbunden und verwenden SSL über eine TCP/IP-Verbindung zu 127.0.0.1. Beachten Sie, dass wir den Datenbanknamen auch in der Befehlszeile für psql angegeben haben. Wenn dies weggelassen wird, wird aus historischen Gründen auch angenommen, dass der Datenbankname mit dem Systembenutzernamen (hier „alice“) identisch ist, was nicht das ist, was wir wollen. Der PostgreSQL-Benutzername wird ebenfalls angegeben („-U myapp_user“).

Wenn Sie sich von anderen Computern aus verbinden müssen, müssen Sie pg_hba.conf bearbeiten um Zeilen wie folgt hinzuzufügen:

# existing entry, allows connections from localhost
host all   all        127.0.0.1/32 md5

# new entry to allow connections from 10.1.2.0/24 subnet,
# only to myapp database for myapp_user
host myapp myapp_user 10.1.2.0/24  md5

und laden Sie PostgreSQL neu („sudo systemctl reload postgresql“), damit die Änderungen wirksam werden.

Damit können Sie jetzt Datenbank-Verbindungszeichenfolgen wie diese in Ihren Apps verwenden:

# URL format
postgresql://myapp_user:[email protected]/myapp

# connection string format
host=127.0.0.1 user=myapp_user dbname=myapp password=s3cr3t

Fertig!

Dadurch sollten Sie eine dedizierte Datenbank und einen dedizierten Benutzer für Ihre App einrichten. Ihr App-Entwicklungs-Framework (wie Django, Drupal usw.) sollte in der Lage sein, Objekte (wie Tabellen, Ansichten) zu erstellen und die Daten in dieser Datenbank zu verwalten.