posizione predefinita di postgresql durante l'installazione tramite apt-get


15

Quando installi postgresql il 14.04, attacca il programma del server principale postgres su:

/usr/lib/postgresql/9.3/bin/postgres

la directory dei dati in cui verranno archiviati tutti i cluster di database in:

/var/lib/postgresql/9.3/main

e il file di configurazione su:

/etc/postgresql/9.3/main/postgresql.conf

Ora capisco perché postgresql.conf e altri file di configurazione sono memorizzati in /etc/postgresql/9.3/main. Dopotutto, / etc è dove i file di configurazione sono memorizzati in un sistema linux.

Tuttavia, perché posizionare l'area di archiviazione del database in / var / lib? Riesco a capire / var, poiché quello è il posto per dati non statici e database non statici. Ma perché / var / lib in particolare?

Inoltre, credo che / bin sia per i programmi richiesti per l'avvio. / usr / bin è per i programmi inclusi nella distribuzione. e / usr / local / bin dovrebbero essere per i programmi non inclusi nella distribuzione ma disponibili per l'uso a livello di sistema. Quindi, poiché postgresql è destinato all'uso a livello di sistema, dovrebbe essere disponibile in / usr / local / bin. Tuttavia, lo inseriscono in / usr / lib, che non ho idea del perché.

Perché faccio questa domanda? Perché senza ordine e struttura, è difficile ricordare la posizione dei programmi che usi tutti i giorni.

Risposte:


11

Nel Filesystem Hierarchy Standard, `/ var / lib / è indicato come (in corsivo la parte più importante):

5.8.1 Scopo

Questa gerarchia contiene informazioni sullo stato relative a un'applicazione o al sistema. Le informazioni sullo stato sono dati che i programmi modificano durante l'esecuzione e che riguardano un host specifico. Gli utenti non devono mai aver bisogno di modificare i file in / var / lib per configurare l'operazione di un pacchetto.

Le informazioni sullo stato vengono generalmente utilizzate per preservare le condizioni di un'applicazione (o di un gruppo di applicazioni correlate) tra invocazioni e tra istanze diverse della stessa applicazione. Le informazioni sullo stato dovrebbero generalmente rimanere valide dopo il riavvio, non devono registrare l'output e non devono essere inviati in spooling.

Un'applicazione (o un gruppo di applicazioni correlate) deve usare una sottodirectory di / var / lib per i suoi dati. C'è una sottodirectory richiesta, / var / lib / misc, che è intesa per i file di stato che non necessitano di una sottodirectory; le altre sottodirectory dovrebbero essere presenti solo se l'applicazione in questione è inclusa nella distribuzione.

/ var / lib / è la posizione che deve essere utilizzata per tutto il supporto del packaging di distribuzione. Distribuzioni diverse possono usare nomi diversi, ovviamente.

In breve: / var / lib / è per i dati utilizzati localmente.

Quindi ha perfettamente senso inserire i dati di un database nella directory / var / lib / {mysql | postgress} / ma ... l'FHS è uno standard creato principalmente per l'uso da parte delle distribuzioni . Come utente sei libero di mettere i tuoi dati dove vuoi ed è principalmente una questione di opinione.


Stai fraintendendo la parola "locale". / usr / local / bin / non è per il software di sistema ma per il proprio software (in pratica qualsiasi cosa con "local" in non deve mai essere toccata dal sistema. Come spiegato da FHS:

/ Usr / local /

4.9.1 Scopo

La gerarchia / usr / local è utilizzata dall'amministratore di sistema durante l'installazione del software in locale. Deve essere sicuro di non essere sovrascritto quando il software di sistema viene aggiornato. Può essere utilizzato per programmi e dati condivisibili tra un gruppo di host, ma non presenti in / usr. Il software installato localmente deve essere posizionato in / usr / local anziché / usr a meno che non sia installato per sostituire o aggiornare il software in / usr.

Un eseguibile installato dal software di sistema non dovrebbe mai andare in qualcosa di locale.


Ora per / usr / lib / .

4.7.1 Scopo

/ usr / lib include file di oggetti, librerie e file binari interni che non sono destinati ad essere eseguiti direttamente da utenti o script di shell. Le applicazioni possono utilizzare una singola sottodirectory in / usr / lib. Se un'applicazione utilizza una sottodirectory, tutti i dati dipendenti dall'architettura utilizzati esclusivamente dall'applicazione devono essere inseriti in tale sottodirectory.

postgressql è probabilmente un demone avviato all'avvio? In tal caso ha senso metterlo qui. Non si suppone di utilizzare il comando da soli ma avviare un servizio. I file in / usr / lib / tendono ad avere il proprio utente e gruppo e / o un demone che limita l'accesso a / var / lib (solo mysqld può accedere a / var / lib / mysql / per esempio; questo sarà lo stesso per PostgreSQL)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.