ubicación predeterminada de postgresql cuando se instala mediante apt-get

Cuando instala postgresql en 14.04, pega el programa principal del servidor postgres en:

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

el directorio de datos donde se almacenarán todos los grupos de bases de datos en:

/var/lib/postgresql/9.3/main

y el archivo de configuración en:

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

Ahora puedo entender por qué postgresql.conf y otros archivos de configuración están almacenados en /etc/postgresql/9.3/main. Después de todo, / etc es donde los archivos de configuración se almacenan en un sistema Linux.

Sin embargo, ¿por qué colocar el área de almacenamiento de la base de datos en / var / lib? Puedo entender / var, ya que ese es el lugar para los datos no estáticos y las bases de datos no son estáticas. Pero, ¿por qué / var / lib en particular?

Además, creo que / bin es para los programas necesarios para el arranque. / usr / bin es para programas incluidos en la distribución. y / usr / local / bin debe ser para programas no incluidos en la distribución pero disponibles para uso en todo el sistema. Y, por lo tanto, dado que postgresql está destinado a todo el sistema, debería estar disponible en / usr / local / bin. Sin embargo, lo colocan en / usr / lib, que no tengo idea de por qué.

¿Por qué hago esta pregunta? Porque sin orden y estructura, es difícil recordar la ubicación de los programas que usa todos los días.

En el Estándar de jerarquía del sistema de archivos, `/ var / lib / se indica como (en cursiva la parte más importante):

5.8.1 Propósito

Esta jerarquía contiene información de estado relacionada con una aplicación o el sistema. La información de estado son datos que los programas modifican mientras se ejecutan, y que pertenecen a un host específico. Los usuarios nunca deben necesitar modificar archivos en / var / lib para configurar la operación de un paquete.

La información de estado generalmente se usa para preservar la condición de una aplicación (o un grupo de aplicaciones interrelacionadas) entre invocaciones y entre diferentes instancias de la misma aplicación. La información de estado generalmente debe seguir siendo válida después de un reinicio, no debe registrar el resultado y no debe contener datos en spool.

Una aplicación (o un grupo de aplicaciones interrelacionadas) debe usar un subdirectorio de / var / lib para sus datos. Hay un subdirectorio requerido, / var / lib / misc, que está destinado a archivos de estado que no necesitan un subdirectorio; los otros subdirectorios solo deberían estar presentes si la aplicación en cuestión está incluida en la distribución.

/ var / lib / es la ubicación que se debe usar para todo el soporte de empaquetado de distribución. Diferentes distribuciones pueden usar diferentes nombres, por supuesto.

En resumen: / var / lib / es para datos que se usan localmente.

Por lo tanto, tiene mucho sentido poner los datos de una base de datos en el directorio / var / lib / {mysql | postgress} / pero ... el FHS es un estándar creado principalmente para su uso por las distribuciones . Como usuario, usted es libre de poner sus datos donde quiera y es principalmente una cuestión de opinión.

Estás malinterpretando la palabra "local". / usr / local / bin / no es para el software del sistema sino para su propio software (básicamente, cualquier cosa con "local" nunca debe ser tocado por el sistema. Como lo explica FHS:

/ usr / local /

4.9.1 Propósito

La jerarquía / usr / local es para uso del administrador del sistema al instalar software localmente. Es necesario evitar que se sobrescriba cuando se actualiza el software del sistema. Se puede usar para programas y datos que se pueden compartir entre un grupo de hosts, pero que no se encuentran en / usr. El software instalado localmente debe colocarse dentro de / usr / local en lugar de / usr a menos que se instale para reemplazar o actualizar el software en / usr.

Un ejecutable instalado desde el software del sistema nunca debe ir a nada local.

Ahora para / usr / lib / .

4.7.1 Propósito

/ usr / lib incluye archivos de objetos, bibliotecas y archivos binarios internos que no están destinados a ser ejecutados directamente por usuarios o scripts de shell. Las aplicaciones pueden usar un solo subdirectorio bajo / usr / lib. Si una aplicación utiliza un subdirectorio, todos los datos dependientes de la arquitectura utilizados exclusivamente por la aplicación deben colocarse dentro de ese subdirectorio.

postgressql es probablemente un demonio iniciado en el arranque? Si es así, tiene sentido ponerlo aquí. Se supone que no debe usar el comando usted mismo sino iniciar un servicio. Los archivos en / usr / lib / tienden a tener su propio usuario y grupo y / o un demonio que restringe el acceso a / var / lib (solo mysqld puede acceder a / var / lib / mysql / por ejemplo; esto será lo mismo para postgressql)