Guida rapida a PostgreSQLPostgreSQL è un sistema libero ed open source per la gestione di basi di dati relazionali. Supporta funzionalità quali le transaction, gli schema e le foreign key, ed è spesso considerato più strettamente aderente agli standard SQL e più sicuro, di default, di ogni altro database, commerciale o meno. Visitare la pagina About su postgresql.org per ulteriori informazioni. Di cosa questo articolo si occupa Questo articolo contiene dettagli, specifici per Gentoo, sull'installazione del database PostgreSQL. Gli ebuild utilizzati in questo articolo sono dev-db/postgresql-docs, dev-db/postgresql-base e dev-db/postgresql-server. In questo articolo si assume che il lettore voglia installare l'ultima versione stabile di PostgreSQL che, al momento di scrivere, è la 9.0.3. Si prega di modificare i comandi che verranno proposti in modo da utilizzare la versione di proprio gradimento.
Gli ebuild per PostgreSQL presenti in Portage ricorrono alla funzionalità di slotting sulla base della versione primaria. Questo consente di avere simultaneamente due instanze di PostgreSQL appartenenti a versioni primarie diverse, ad esempio la 8.4 e la 9.0. Ciò è utile nel caso in cui si debbano spostare dati da un vecchio database ad uno nuovo, oppure qualora occorra installare sulla stessa macchina un database sperimentale ed uno in produzione. Inoltre questa funzionalità impedisce che un database venga sovrascritto da un aggiornamento incompatibile, assieme alle librerie e agli eseguibili corrispondenti. Questo infatti richiederebbe una migrazione, che ad ogni modo è descritta in questa guida. Bug e problemi di sicurezza possono invece essere corretti effettuando semplici aggiornamenti che si contraddistinguono per una variazione della sola versione secondaria, e possono essere applicati senza timore di corrompere un database o l'installazione stessa di PostgreSQL; la versione 9.0.2 può essere facilmente aggiornata alla 9.0.3 in quanto la loro compatibilità è garantita, e ciò richiede soltanto il riavvio del processo; non sono necessarie la migrazione, la riconfigurazione o l'inizializzazione. Leggere la pagina sulle regole in merito alle versioni di PostgreSQL per maggiori informazioni. Di cosa questo articolo non si occupa Molti aspetti non verranno trattati. Basti pensare che la documentazione ufficiale consiste in approssimativamente 2000 pagine, e questa invece è una guida rapida. Ci si occuperà solo di problematiche specifiche derivanti dall'impiego di PostgreSQL in ambiente Gentoo, oltre a qualche raccomandazione per una configurazione di base. Qualora sul proprio sistema sia ancora presente uno qualunque dei seguenti ebuild è necessario subito effettuare una migrazione: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq e dev-db/postgresql. Questo articolo si occupa della migrazione dai vecchi ebuild a quelli nuovi.
È possibile che uno o più tra i paccheti riportati sopra risulti essere bloccato da uno o più tra i seguenti pacchetti: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq o dev-db/postgresql. Questi pacchetti non sono più supportati e sono obsoleti. Si prega di consultare la sezione sulla migrazione per sapere come gestire questa situazione. Preparazione all'inizializzazione del cluster di database Una volta terminata l'installazione dei pacchetti si può procedere alla modifica del file /etc/conf.d/postgresql-9.0. Ci sono tre righe che non possono essere cambiate in seguito senza dover prima procedere all'eliminazione della directory che contiene il cluster di database e alla reinizializzazione. PGDATA definisce la posizione dei file di configurazione. DATA_DIR definisce invece il luogo in cui creare il cluster di database e i file ad esso correlati. PG_INITDB_OPTS, infine, può contenere opzioni extra a discrezione dell'utente. Tali opzioni extra, tuttavia, non sono in alcun modo obbligatorie in quanto le opzioni predefinite sono del tutto ragionevoli. Nel seguente esempio PGDATA dichiara che i file di configurazione sono posti in /etc/postgresql-9.0/. DATA_DIR dichiara invece che il cluster di database è posto in /var/lib/postgresql/9.0/data/ (la directory predefinita). Qualora le scelte del lettore differissero da quelle predefinite si tenga conto che è comunque un'ottima idea mantenere la versione primaria nel percorso. PG_INITDB_OPTS dichiara infine che il locale di default è en_US.UTF-8, e che cioè verranno usati l'ordinamento e la formattazione dell'inglese americano, e la codifica dei caratteri UTF-8.
Ci sono sei opzioni che, se usate, hanno la precedenza su --locale=. La seguente tabella elenca le sei opzioni per le quali è necessario usare lo schema --opzione=lo_LO.ENCODING.
Se ad esempio l'utente vuole che l'inglese sia la lingua predefinita ma che i messaggi vengano visualizzati in svedese occorre definire PG_INITDB_OPTS nel seguente modo:
Un elenco completo delle lingue e delle codifiche dei caratteri supportate dal server è disponibile nella documentazione, ma anche il sistema deve supportarle. Il lettore può confrontare l'output del comando locale -a con la pagina nella documentazione sulle codifiche . È possibile cambiare il locale e la codifica dei caratteri al momento della creazione di un database, mentre per farlo successivamente è necessario effettuare il drop del database e iniziare da capo.
Questo comando crea il cluster di database e memorizza tutti i file corrispondenti in PGDATA e DATA_DIR. Posizione dei file di configurazione Questa volta l'attenzione sarà focalizzata sui file che si trovano nella directory definita da PGDATA, /etc/postgresql-9.0, ed in particolare sui file postgresql.conf e pg_hba.conf. Questo è il file di configurazione principale. Di immediato interesse è la riga con listen_addresses. Questa variabile definisce infatti gli indirizzi ai quali PostgreSQL effettua il binding. Normalmente esso è effettuato solo con localhost e con i socket Unix. Cambiare listen_addresses non è sufficiente se si vogliono abilitare le connessioni remote. Questo argomento verrà affrontato nella prossima sezione. La documentazione ufficiale è abbastanza semplice da comprendere ed è piuttosto esauriente. Si consiglia di leggere anche quella in aggiunta a ciò che è scritto qui in quanto alcune cose possono differire. Di secondaria importanza è il percorso per i file di log. Normalmente tutto viene memorizzato in postmaster.log nella directory DATA_DIR. Esiste un'intera sottosezione in postgresql.conf con numerose opzioni per come, dove e di cosa effettuare il log. Questa sottosezione è indicata con: ERROR REPORTING AND LOGGING. A parte listen_addresses e le opzioni per il logging, le altre impostazioni predefinite sono piuttosto ragionevoli, e consentono al lettore di procedere oltre. Il file di configurazione pg_hba.conf serve ad indicare coloro i quali possiedono l'autorizzazione a connettersi al server e quale metodo di autenticazione deve essere usato per stabilire tale connessione. Ancora una volta la documentazione è piuttosto esauriente nel spiegare il significato di ciascuna opzione, ma alcune cose sono trattate qui al fine di chiarire alcuni punti.
Come si accennava in precedenza, il server è abbastanza sicuro anche nelle sue impostazioni predefinite. L'unico database di cui si effettua il log è postgres. Inoltre l'unico modo per stabilire una connessione al database è tramite il socket Unix /var/run/postgresql/.s.PGSQL.5432, che appartiene all'utente e al gruppo di sistema postgres, oppure tramite localhost. Ad ogni modo ogni utente del sistema può stabilire una connessione con il database tramite localhost, anche come utente amministratore del database postgres. Tuttavia per stabilire una connessione tramite il socket Unix gli utenti, compresi quelli di altri servizi come apache, devono appartenere al gruppo di sistema postgres. Il lettore può usare il comando gpasswd -a utente postgres per aggiungere utente al gruppo postgres. Agli utenti che non appartengono al gruppo postgres viene negato l'accesso con il messaggio "Permission denied".
Il metodo trust è quello che permette ad ogni utente del sistema di effettuare l'accesso come un qualunque utente del database senza fornire la password. In altre parole questo metodo specifica che occorre consentire ogni connessione verso un determinato database ad ogni utente del database stesso (ma non da ogni utente di sistema) senza fornire una password, a patto comunque che la provenienza e il tipo della connessione siano quelli previsti. Ciò non è così pericoloso come può apparire in prima battuta, ma costituisce comunque un serio rischio per la sicurezza nelle circostanze più comuni. I due metodi che vengono generalmente utilizzati sono password e md5. Il metodo password specifica che una password è necessaria per stabilire una connessione e che essa viene trasmessa in chiaro. Questo metodo è appropriato quando tali informazioni non lasciano la macchina da cui provengono, ad esempio nel caso in cui ci si connette tramite il socket unix o localhost. Il metodo md5 è simile al precedente, ma protegge la password adoperando un hash md5. È questo il metodo preferito qualora la password debba attraversare una rete. A questo punto è possibile concentrarsi sulle ultime due righe (quattro se si includono i commenti) del file pg_hba.conf. PostgreSQL supporta nativamente il protocollo IPv6 indipendentemente dalle esigenze dell'utente. Inoltre agli indirizzi IPv4 sono automaticamente associati indirizzi IPv6. Ad esempio a 127.0.0.1 viene associato ::FFFF:127.0.0.1 e l'indirizzo "puro" ::FFFF:7F00:0001. Sembra comunque esserci un'incomprensione quanto alle modalità con le quali ai nomi di host vengono associati gli indirizzi IP. Il file di riferimento è /etc/hosts.
Dall'esempio precedente è possibile notare che ad entrambi gli indirizzi IPv4 e IPv6 viene associato localhost. Quando consulta questo file psql prende la prima corrispondenza e usa quella come indirizzo, in questo caso 127.0.0.1. Quando analizza il file PostgreSQL usa anche il corrispondende indirizzo IPv6, ovvero ::ffff:127.0.0.1. Se invece l'indirizzo IPv6 appare prima, allora psql usa soltanto ::1, e ::1 non equivale a ::ffff:127.0.0.1. In questo caso infatti se a ::1 non corrisponde un valido metodo di accesso, psql non sarà in grado di stabilire una connessione. Inoltre il kernel deve supportare il protocollo IPv6. È quindi meglio specificare soltanto gli indirizzi IP per psql in pg_hba.conf piuttosto che dipendere da un corretto ordinamento interno al file /etc/hosts, dal momento che ciò elimina ogni possibile dubbio in merito a quali indirizzi IP siano ammessi o a quale server ci si connette. Occorre ora avviare PostgreSQL e impostare la password per l'utente postgres. I seguenti comandi vanno impartiti dall'utente root:
A questo punto si può proseguire con il tutorial ufficiale di PostgreSQL, che guida il lettore nella creazione dei role, dei database e degli schema. Casi in cui occorre effettuare una migrazione Ci sono solo due casi in cui occorre effettuare una migrazione: quando si passa da una versione principale ad un'altra, ad esempio dalla versione 8.4.7 di PostgreSQL alla versione 9.0.3 (ma non dalla 9.0.2 alla 9.0.3); o quando si passa dal vecchio formato a virgola mobile per i timestamp a quello nuovo basato su numeri interi a 64-bit.
Migrazione per versioni a partire dalla 9.0 pg_upgrade è un nuovo strumento, disponibile a partire dalla versione 9.0, che semplifica molto il processo di migrazione. Ci sono però due fattori che bisogna considerare quando si usa pg_upgrade. Il primo è che pg_upgrade non supporta il caso in cui i file di configurazione siano in una directory differente da quella in cui si trovano i dati. Questo problema può essere risolto usando i collegamenti simbolici. Il secondo è che pg_upgrade può essere usato solo per effettuare la migrazione di database creati con una versione di PostgreSQL pari o superiore alla 8.3. Se si dispone di database più vecchi è necessario leggere le istruzioni specifiche per versioni precedenti alla 9.0.
Migrazione per versioni precedenti alla 9.0 (con i nuovi ebuild) I nuovi ebuild dispongono di funzionalità di slotting più avanzate rispetto a quelle degli ebuild precedenti, e pertanto il downtime dovrebbe essere abbastanza ridotto (minuti anzichè ore). Negli esempi successivi si assume che l'utente stia usando valori predefiniti per i percorsi e le porte, e che stia migrando dalla versione 8.3 alla 8.4. Si prega di modificare opportunamente le istruzioni nel caso in cui ciò non sia vero. Qualora non lo si abbia ancora fatto, prima di effettuare la migrazione è necessario seguire le instruzioni per l'installazione . Il processo di compilazione potrebbe ridurre le prestazioni del server, ma esso continuerebbe comunque a funzionare. È necessario modificare un paio di file prima di iniziare con il processo di migrazione. Impostare PGPORT in /etc/conf.d/postgresql-8.4 al valore 6543. In generale va bene ogni valore diverso da quello della porta alla quale prestava ascolto la vecchia versione di PostgreSQL. Modificare quindi il file /etc/postgresql-8.3/pg_hba.conf in modo tale che solo l'amministratore del database (postgres) possa accedere al cluster tramite il socket Unix.
A questo punto si spera che tutto sia andato per il meglio è che il nuovo server contenga gli stessi dati di quello vecchio. Migrazione per versioni precedenti alla 9.0 (con i vecchi ebuild) I vecchi ebuild non possono essere installati contemporaneamente a quelli nuovi. Per questo motivo sarà necessario interrompere l'attività del proprio server per alcune ore. Si consiglia di programmare in anticipo questa operazione ed effettuarla ad esempio nel fine settimana. Prima di iniziare con la migrazione occorre negare l'accesso al server, in modo tale che non venga fatto alcun cambiamento. È possibile anche che il lettore voglia effettuare il backup dei file postgresql.conf e pg_hba.conf, o di ogni altro file che si reputa importante.
È possibile che alcuni pacchetti risultino ora corrotti perchè dipendono da quelli che sono stati rimossi, ma dopo aver installato dev-db/postgresql-base e/o dev-db/postgresql-server è possibile eseguire revdep-rebuild in modo tale da reinstallare ogni pacchetto corrotto. pgAdmin III è uno strumento grafico per la gestione di PostgreSQL. Al server mancano le funzioni strumentali Questo è un problema facile da risolvere, e la soluzione dipende dalla versione in uso. È necessario importare le funzioni strumentali dal file adminpack.sql. Eseguire il comando corrispondente alla propria versione:
I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike. |
|