[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home] [volume] [parte]


Capitolo 696.   PostgreSQL: struttura e preparazione

PostgreSQL (1) è un DBMS (Data base management system) relazionale, esteso agli oggetti. In questo capitolo si vuole introdurre al suo utilizzo e accennare alla sua struttura, senza affrontare le particolarità del linguaggio di interrogazione. Il nome lascia intendere che si tratti di un DBMS in grado di comprendere le istruzioni SQL.

696.1   Struttura dei dati nel file system

PostgreSQL, a parte i programmi binari, gli script e la documentazione, colloca i file di gestione delle basi di dati a partire da una certa directory, che nella documentazione originale viene definita PGDATA. Questo è il nome di una variabile di ambiente che può essere utilizzata per informare i vari programmi di PostgreSQL della sua collocazione; tuttavia, di solito questo meccanismo della variabile di ambiente non viene utilizzato, specificando tale directory in fase di compilazione dei sorgenti oppure avviando i programmi con opzioni appropriate.

Tutti i programmi che compongono il sistema di PostgreSQL, che hanno la necessità di sapere dove si trovano i dati, oltre al meccanismo della variabile di ambiente PGDATA permettono di indicare tale directory attraverso un'opzione della riga di comando. I programmi più importanti riconoscono l'opzione -D. Come si può intuire, l'utilizzo di questa opzione, o di un'altra equivalente per gli altri programmi, fa in modo che l'indicazione della variabile PGDATA non abbia effetto.

Questa directory è contenuta solitamente nella directory iniziale dell'utente di sistema per l'amministrazione di PostgreSQL, che dovrebbe essere postgres. La directory iniziale dell'utente postgres (ovvero ~postgres/) è normalmente /var/lib/postgres/; la directory usata normalmente per collocarvi le basi di dati è normalmente ~postgres/data/, ovvero /var/lib/postgres/data/. Di norma, tutto ciò che si trova a partire da ~postgres/ appartiene all'utente postgres, anche se i permessi per il gruppo e gli altri utenti variano a seconda della circostanza.

Inizialmente, la directory che costituisce l'inizio delle basi di dati (~postgres/data/) dovrebbe contenere dei file di configurazione, una basi di dati amministrativa (trasparente) e una base di dati da usare come modello per la produzione di altre (template1) o semplicemente per accedere al DBMS quando non se ne può indicare un'altra. Naturalmente, se per qualche ragione si utilizza l'utenza postgres in modo normale, nella sua directory personale (~postgres/) potrebbero apparire dei file che riguardano la personalizzazione di questo utente (.profile, .bash_history, o altre cose simili, in funzione dei programmi che si utilizzano).

696.2   Amministratore

L'amministratore dei servizi offerti dal DBMS PostgreSQL potrebbe essere una persona diversa dall'amministratore del sistema operativo (l'utente root) e corrisponde di solito all'utente postgres. In condizioni normali, tale utente del DBMS viene riconosciuto implicitamente da PostgreSQL, purché acceda localmente utilizzando un'utenza del sistema operativo con lo stesso nome.

Quando la propria distribuzione GNU è già predisposta per PostgreSQL, l'utente postgres dovrebbe essere stato previsto (non importa il numero UID che gli sia stato abbinato), ma quasi sicuramente la parola d'ordine per l'accesso al sistema operativo dovrebbe essere «impossibile», come nell'esempio seguente:

postgres:!:101:101:PostgreSQL Server:/var/lib/postgres:/bin/bash

Come si vede, in questo esempio il campo della parola d'ordine è occupato da un punto esclamativo che di fatto impedisce l'accesso all'utente postgres.

A questo punto si pongono due alternative, a seconda che si voglia affidare la gestione del DBMS allo stesso utente root oppure che si voglia incaricare per questo un altro utente. Nel primo caso non occorrono cambiamenti: l'utente root può diventare postgres quando vuole con il comando su.

su postgres[Invio]

Nel secondo caso, l'attribuzione di una parola d'ordine all'utente postgres permetterebbe a una persona diversa di amministrare il DBMS.

passwd postgres[Invio]

Di solito, nella sua configurazione iniziale, l'utente postgres ha la facoltà di accedere localmente al DBMS, senza bisogno di altre forme di autenticazione, a parte il fatto di essere riconosciuto dal sistema operativo proprio con quello stesso nome. Ciò dipende principalmente dalla configurazione contenuta nel file pg_hba.conf, che viene descritto in seguito, all'interno di questo capitolo. Negli esempi che si mostrano qui, si presume proprio che l'utente postgres del sistema operativo, in quanto tale, sia riconosciuto così anche dal DBMS; se così non fosse, a causa della configurazione, è probabile vedere apparire la richiesta di introdurre una parola d'ordine, riferita però al DBMS.

696.3   Creazione del sistema di basi di dati

La prima volta che si installa PostgreSQL, è molto probabile che venga predisposta automaticamente la directory ~postgres/. Se così non fosse, o se per qualche motivo si dovesse intervenire manualmente, si può utilizzare initdb, che però potrebbe risiedere al di fuori dei percorsi normali contenuti nella variabile $PATH; precisamente potrebbe trattarsi della directory /usr/lib/postgresql/bin/.

[percorso]initdb [opzioni] [--pgdata=directory |-D directory]

Lo schema sintattico mostra in modo molto semplice l'uso di initdb. Se si definisce correttamente la variabile di ambiente PGDATA, si può fare anche a meno delle opzioni, diversamente diventa necessario dare questa informazione attraverso l'opzione -D.

Volendo fare tutto da zero, occorre predisporre la directory iniziale in modo che appartenga dell'utente fittizio postgres:

mkdir ~postgres[Invio]

chown postgres: ~postgres[Invio]

Prima di avviare initdb, è bene utilizzare l'identità dell'utente amministratore di PostgreSQL:

su postgres[Invio]

Successivamente, si deve avviare initdb specificando la directory a partire dalla quale si devono articolare i file che costituiscono le basi di dati. Come già descritto, la directory in questione è normalmente ~postgres/data/:

postgres$ /usr/lib/postgresql/bin/initdb --locale=it_IT.UTF-8 \
  \--encoding=UNICODE --pgdata=/var/lib/postgres/data
[Invio]

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale it_IT.UTF-8.

creating directory /var/lib/postgres/data... ok
creating directory /var/lib/postgres/data/base... ok
creating directory /var/lib/postgres/data/global... ok
creating directory /var/lib/postgres/data/pg_xlog... ok
creating directory /var/lib/postgres/data/pg_clog... ok
selecting default max_connections... 100
selecting default shared_buffers... 1000
creating configuration files... ok
creating template1 database in /var/lib/postgres/data/base/1... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
creating information schema... ok
vacuuming database template1... ok
copying template1 to template0... ok

Success. The database server should be started automatically.
If not, you can start the database server using:

    /etc/init.d/postgresql start

Nell'esempio sono state usate anche due opzioni il cui significato dovrebbe risultare intuitivo.

Tabella 696.3. Alcune opzioni per l'uso di initdb.

Opzione Descrizione
--pgdata=directory_pgdata
-D directory_pgdata
Stabilisce la directory iniziale del sistema di basi di dati di PostgreSQL che si vuole creare. Di solito deve corrispondere a ~postgres/data/.
--locale=sigla_locale
Stabilisce la configurazione locale. Se non viene utilizzata questa opzione si usa il contenuto delle variabili di ambiente LANG ed eventualmente LC_*.
--encoding=codifica
-E codifica
Stabilisce la codifica della base di dati usata come modello (template1), diventando di conseguenza la codifica predefinita per le nuove basi di dati. Tra le varie sigle che si possono usare vale la pena di ricordare UNICODE, SQL_ASCII.

Teoricamente, initdb fa tutto quello che è necessario fare; in pratica potrebbe non essere così. La prima cosa da considerare sono i file di configurazione, che, seguendo l'esempio mostrato, vengono collocati nella directory ~postgres/data/. Molto probabilmente la propria distribuzione GNU è organizzata per avere i file di configurazione in una directory /etc/postgresql/, o simile. Se le cose stanno così, bisogna provvedere a sostituire i file di configurazione nella directory ~postgres/data/ con dei collegamenti simbolici appropriati.

Le distribuzioni GNU possono avere la necessità di passare alcune informazioni, tramite variabili di ambiente, all'utente fittizio postgres, cosa che si ottiene con un file ~postgres/.profile appropriato. Se si vuole ricreare la directory ~postgres/ da zero, ma si nota la presenza di file di configurazione della shell, è necessario accertarsi del loro contenuto e provvedere di conseguenza nella ricostruzione della directory.

Un'ultima questione importante da sistemare è la directory ~postgres/dumpall/, che serve a contenere versioni vecchie degli eseguibili di PostgreSQL, con lo scopo di recuperare i dati dalle versioni vecchie delle basi di dati. Normalmente è sufficiente recuperare la directory già usata in precedenza.

696.4   Avvio del servizio

Il DBMS di PostgreSQL si basa su un sistema cliente-servente, in cui, il programma che vuole interagire con una base di dati determinata deve farlo attraverso delle richieste inviate a un servente. In questo modo, il servizio può essere esteso anche attraverso la rete.

L'organizzazione di PostgreSQL prevede la presenza di un demone sempre in ascolto (può trattarsi di un socket di dominio Unix o anche di una porta TCP, che di solito corrisponde al numero 5 432). Quando questo riceve una richiesta valida per iniziare una connessione, attiva una copia del servente vero e proprio (back-end), a cui affida la connessione con il cliente. Il demone in ascolto per le richieste di nuove connessioni è postmaster, mentre il servente è postgres.

Purtroppo, la scelta del nome «postmaster» è un po' infelice, dal momento che potrebbe far pensare all'amministratore del servizio di posta elettronica. Come al solito occorre un po' di attenzione al contesto in cui ci si trova.

Generalmente, il demone postmaster viene avviato attraverso la procedura di inizializzazione del sistema, in modo indipendente dal supervisore dei servizi di rete. In pratica, di solito si utilizza uno script collocato all'interno di /etc/init.d/, o in un'altra collocazione simile, per l'avvio e l'interruzione del servizio.

Durante il funzionamento del sistema, quando alcuni clienti sono connessi, si può osservare una dipendenza del tipo rappresentato dallo schema seguente:

--postmaster-+-postgres
             |-postgres
             `-postgres

Il demone postmaster si occupa di restare in ascolto in attesa di una richiesta di connessione con un servente postgres (il programma terminale, o back-end in questo contesto). Quando riceve questo tipo di richiesta mette in connessione il cliente (programma frontale, o front-end) con una nuova copia del servente postgres.

postmaster [opzioni]

Per poter compiere il suo lavoro, il demone deve essere a conoscenza di alcune notizie essenziali, tra cui in particolare: la collocazione del programma postgres (se questo non è in uno dei percorsi della variabile PATH) e la directory da cui si dirama il sistema di file che costituisce l'insieme delle varie basi di dati. Queste notizie possono essere predefinite, nella configurazione usata al momento della compilazione dei sorgenti, oppure possono essere indicate attraverso la riga di comando.

Il demone postmaster e i processi terminali da lui controllati, gestiscono una serie di file che compongono le varie basi di dati del sistema. Trattandosi di un sistema di gestione dei dati molto complesso, è bene evitare di inviare il segnale SIGKILL (9), perché con questo si provoca la conclusione immediata del processo destinatario e di tutti i suoi discendenti, senza permettere una conclusione corretta. Al contrario, gli altri segnali sono accettabili, come per esempio un SIGTERM che viene dato in modo predefinito quando si utilizza il comando kill.

Tabella 696.5. Alcune opzioni per l'avvio di postmaster.

Opzione Descrizione
-D directory_dei_dati
Permette di specificare la directory di inizio della struttura dei dati del DBMS.
-S
Specifica che il programma deve funzionare in modo «silenzioso», senza emettere alcuna segnalazione, diventando un processo discendente direttamente da quello iniziale (Init), disassociandosi dalla shell e quindi dal terminale da cui è stato avviato.
Questa opzione viene utilizzata particolarmente per avviare il programma all'interno della procedura di inizializzazione del sistema, quando non sono necessari dei controlli di funzionamento.
-b percorso_del_programma_terminale
Se il programma terminale, ovvero postgres, non si trova in uno dei percorsi contenuti nella variabile di ambiente PATH, è necessario specificare la sua collocazione (il percorso assoluto) attraverso questa opzione.
-d [livello_di_diagnosi]
Questa opzione permette di attivare la segnalazione di messaggi diagnostici (debug), da parte di postmaster e da parte dei programmi terminali, a più livelli di dettaglio:
1, segnala solo il traffico di connessione;
2, o superiore, attiva la segnalazione diagnostica anche nei programmi terminali, oltre ad aggiungere dettagli sul funzionamento di postmaster.
Di norma, i messaggi diagnostici vengono emessi attraverso lo standard output da parte di postmaster, anche quando si tratta di messaggi provenienti dai programmi terminali. Perché abbia significato l'uso di questa opzione, occorre avviare postmaster senza l'opzione -S.
-i
Abilita le connessioni TCP/IP. Senza l'indicazione di questa opzione, sono ammissibili solo le connessioni locali attraverso socket di dominio Unix (Unix domain socket).
-p porta
Se viene avviato in modo da accettare le connessioni attraverso la rete (l'opzione -i), specifica una porta di ascolto diversa da quella predefinita (5 432).

Segue la descrizione di alcuni esempi.

Riquadro 696.6. Controllo diagnostico.

Inizialmente, l'utilizzo di PostgreSQL si può dimostrare poco intuitivo, soprattutto per ciò che riguarda le segnalazioni di errore, spesso troppo poco esplicite. In caso di difficoltà, per permettere di avere una visione un po' più chiara di ciò che accade, sarebbe bene fare in modo che postmaster produca dei messaggi diagnostici, possibilmente diretti a un file o a una console virtuale inutilizzata.

Per avere una visione immediata di ciò che accade, l'esempio seguente avvia postmaster in modo manuale e, oltre a conservare le informazioni diagnostiche in un file, le visualizza continuamente attraverso una console virtuale inutilizzata, che in questo caso è l'ottava:

su postgres[Invio]

nohup postmaster -D/var/lib/postgres/data -d 1 \
  \> /var/log/pglog 2>&1 &
[Invio]

exit[Invio]

nohup tail -f /var/lib/postgres > /dev/tty8 &[Invio]

696.5   Configurazione del DBMS

Come già accennato, è possibile influenzare il comportamento del servente PostgreSQL attraverso opzioni della riga di comando e variabili di ambiente. Oltre a questi metodi, è possibile intervenire nel file ~postgres/data/postgresql.conf, attraverso direttive che assomigliano all'assegnamento di variabili. Il loro significato dovrebbe risultare intuitivo. Viene mostrato un estratto di esempio di questo file:

# PostgreSQL configuration file
...
#
# TCP/IP access is allowed by default, but the default access given in
# pg_hba.conf will permit it only from localhost, not other machines.
#
tcpip_socket = true
...
#
#       Message display
#
log_connections = true
log_pid = true
log_timestamp = true
...
#
#       Syslog
#
syslog = 2      # range 0-2
...
#
#       Misc
#
dynamic_library_path = '/usr/share/postgresql:/usr/lib/postgresql:/usr/lib/postgresql/lib'
...
#
# How (by default) to present dates to the frontend; the user can override
# this setting for his own session. The choices are:
#   Style      Date            Timestamptz
#   ----------------------------------------------------------------
#   ISO        1999-07-17      1999-07-17 07:09:18+01
#   SQL        17/07/1999      17/07/1999 07:09:19 BST
#   POSTGRES   17-07-1999      Sat 17 Jul 07:09:19 1999 BST
#   GERMAN     17.07.1999      17.07.1999 07:09:19 BST
#
# It is also possible to specify month-day or day-month ordering in date
# input and output.  Americans tend to use month-day; Europeans use
# day-month.  Specify European or US.  This is used for interpreting
# date input, even if the output format is ISO.  Separate the two parameters
# by a comma with no spaces
#
datestyle = 'ISO,European'
...
LC_MESSAGES = 'C'
LC_MONETARY = 'C'
LC_NUMERIC = 'C'
LC_TIME = 'C'

Si può osservare la direttiva tcpip_socket = true, che abilita l'accesso al servente attraverso la rete, ma che richiede di specificare meglio le possibilità di accesso attraverso il file ~postgres/data/pg_hba.conf.

Tabella 696.8. Elenco dei formati di data gestibili con PostgreSQL.

Stile Descrizione Esempio
ISO
ISO 8601 2007-12-31
SQL
Tipo tradizionale 12/31/2007
POSTGRESQL
Tipo specifico di PostgreSQL 12-31-2007
GERMAN
31.12.2007

Nel caso particolare della distribuzione GNU/Linux Debian, può essere controllato tutto a partire dai file che si trovano nella directory /etc/postgresql/. In particolare, si trova in questa directory il file pg_hba.conf e il file postgresql.conf, già descritti in altre sezioni; inoltre, si trova un file aggiuntivo che viene interpretato dallo script della procedura di inizializzazione del sistema che si occupa di avviare e di arrestare il servizio. Si tratta dei file /etc/postgresql/postmaster.conf, attraverso il quale si possono controllare delle piccole cose a cui non si può accedere con il file postgresql.conf, che altrimenti richiederebbero di intervenire attraverso le opzioni della riga di comando del demone relativo.

696.6   Accesso e autenticazione

L'accesso alle basi di dati viene permesso attraverso un sistema di autenticazione. I sistemi di autenticazione consentiti possono essere diversi e dipendono dalla configurazione di PostgreSQL fatta all'atto della compilazione dei sorgenti.

Il file di configurazione pg_hba.conf (Host-based authentication), che si trova nella directory ~postgres/data/, serve per controllare il sistema di autenticazione una volta installato PostgreSQL.

L'autenticazione degli utenti può avvenire in modo incondizionato (trust), dove ci si fida del nome fornito come utente del DBMS, senza richiedere altro.

L'autenticazione può essere semplicemente disabilitata, nel senso di impedire qualunque accesso incondizionatamente. Questo può servire per impedire l'accesso da parte di un certo gruppo di nodi.

L'accesso può essere controllato attraverso l'abbinamento di una parola d'ordine agli utenti di PostgreSQL.

Inoltre, l'autenticazione può avvenire attraverso un sistema Kerberos, oppure attraverso il protocollo IDENT (capitolo 389). In questo ultimo caso, ci si fida di quanto riportato dal sistema remoto il quale conferma o meno che la connessione appartenga a quell'utente che si sta connettendo.

Il file ~postgres/data/pg_hba.conf (ma spesso questo è un collegamento simbolico che punta a /etc/postgresql/pg_hba.conf o a un'altra posizione simile) permette di definire quali nodi possono accedere al servizio DBMS di PostgreSQL, eventualmente stabilendo anche un abbinamento specifico tra basi di dati, utenti e nodi di rete.

Le righe vuote e il testo preceduto dal simbolo # vengono ignorati. I record (cioè le righe contenenti le direttive del file in questione) sono suddivisi in campi separati da spazi o caratteri di tabulazione. Il formato può essere semplificato nei due modelli sintattici seguenti, tenendo conto che esistono comunque altri casi:

local base_di_dati utente_dbms autenticazione_utente [mappa]
host base_di_dati utente_dbms indirizzo_ip maschera_degli_indirizzi autenticazione_utente [mappa]

Nel primo caso si intendono controllare gli accessi provenienti da programmi clienti avviati nello stesso sistema locale, utilizzando un socket di dominio Unix per il collegamento; nel secondo si fa riferimento ad accessi attraverso la rete (connessioni TCP).

Tabella 696.9. Parole chiave che possono essere usate nel campo autenticazione_utente.

Autenticazione Descrizione
trust
L'autenticazione non ha luogo e si accetta il nome fornito dall'utente senza alcuna verifica.
reject
La connessione viene rifiutata in ogni caso.
password
Viene richiesta una parola d'ordine riferita all'utente del DBMS.
md5
crypt
Viene richiesta una parola d'ordine riferita all'utente del DBMS, che però viene trasmessa in modo cifrato. Le due parole chiave si riferiscono a sistemi differenti; si osservi che, di solito, solo uno dei due sistemi può essere utilizzato, perché dipende dal modo in cui sono memorizzate le parole d'ordine. Pertanto, se uno dei due non funziona, si può tentare con l'altro (dopo aver verificato che comunque l'accesso con le parole d'ordine in chiaro funziona regolarmente).
ident sameuser
ident mappa
L'autenticazione avviene attraverso il sistema operativo locale, oppure con il protocollo IDENT per gli accessi remoti (capitolo 389). Si usa questa modalità di riconoscimento, prevalentemente per gli accessi locali, ma in tal caso si mette quasi sicuramente anche l'opzione sameuser, per fare riferimento allo stesso utente del sistema operativo. Se non si utilizza la parola chiave sameuser, al suo posto va messo il nome di una «mappa», da definire in un altro file.
pam [servizio]
L'autenticazione avviene attraverso il sistema PAM (Pluggable authentication modules) del sistema operativo. Se non viene indicato il servizio PAM, si intende postgresql.

Segue la descrizione di alcuni esempi.

L'esempio seguente rappresenta una configurazione che potrebbe essere considerata «ragionevole», per poter utilizzare l'utente postgres, localmente, senza bisogno di fornire una parola d'ordine (come richiesto dagli esempi mostrati in questo capitolo), consentendo agli altri utenti di accedere da una rete locale qualunque (lo si determina in base al fatto che si fa riferimento a indirizzi IPv4 privati), ma in tal caso si richiede un riconoscimento basato su una parola d'ordine:

#
# TYPE  DATABASE   USER      IP-ADDRESS     IP-MASK          METHOD
#
local   all        postgres                                  ident sameuser
#
local   all        all                                       password
host    all        all       127.0.0.1      255.0.0.0        password
host    all        all       192.168.0.0    255.255.0.0      password
host    all        all       172.16.0.0     255.240.0.0      password
host    all        all       10.0.0.0       255.0.0.0        password
#
host    all        all       0.0.0.0        0.0.0.0          reject 

696.7   Riferimenti


1) PostgreSQL   software libero con licenza speciale


Appunti di informatica libera 2008 --- Copyright © 2000-2008 Daniele Giacomini -- <appunti2 (ad) gmail·com>


Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome postgresql_struttura_e_preparazione.htm

[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [indice analitico] [home]

Valid ISO-HTML!

CSS validator!

Gjlg Metamotore e Web Directory