Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

lunes, 29 de febrero de 2016

Si buscas encontrarás: find en Linux

Cualquiera que haya usado Linux desde la consola sabe que uno de los principales quebraderos de cabeza de uno es la búsqueda de archivos dentro del sistema... Sin ayudas gráficas ni recursos "intuitivos" más de uno se vuelve loco usando diferentes combinaciones de los comandos cd, ls y grep, pero la mayoría de las veces no es necesario recurrir a dichos términos, pues afortunadamente existe un potentísimo buscador en Linux que puede ayudarnos a encontrar todo lo que necesitemos: El comando find. Desde búsquedas "simples" a búsquedas profundas, find puede ayudarnos a encontrar la aguja en el pajar en cuestión de segundos.

find_portada

Para entender bien esta gran herramienta, lo primero que uno debe conocer a la perfección es la estructura sobre la que trabaja ésta pues regirá cualquier búsqueda que queramos hacer. Dicha estructura sería:

find directorio_búsqueda criterios_búsqueda acción_a_ejecutar

Estructura que si desgranásemos tendría el siguiente significado:

  • directorio_búsqueda: Ruta desde la que comenzar a buscar; en caso de haber directorios dentro de dicha ruta, también buscarían en éstos, con lo que si se comenzase a buscar desde el directorio raíz (/), comenzaríamos la búsqueda desde el directorio del que "cuelgan" el resto y buscaríamos en todo el sistema.
  • criterios_búsqueda: Después de especificar donde comenzar a buscar es necesario decir qué es lo que se desea buscar; esto se determina mediante una serie de criterios y parámetros que nos pueden ayudar a encontrar aquello que deseemos. Esta es la parte más importante del comando ya que es la que determinará qué es lo que se quiere encontrar.
  • acción_a_ejecutar: Tras encontrar lo que deseamos, podemos hacer que de forma OPCIONAL se ejecute algo; es decir que ejecute un comando sobre lo encontrado; esto es bastante delicado y dependiendo del tipo de acción es aconsejable extremar las precauciones.

Ahora que conocemos la estructura, si observamos bien veremos que lo más importante de todo son los criterios que deseamos utilizar para la búsqueda; criterios que dependiendo de su "potencia" son más usados que otros... Englobar todos ellos es complicado, más aún cuando hay muchos criterios que no son usados, pero hay otros muchos que sí, criterios en los cuales me quiero enfocar.

Lo más básico

Aunque find es muy potente y versátil, la mayoría de las búsquedas realizadas por los usuarios son relativamente sencillas, búsquedas que se pueden hacer únicamente conociendo las búsquedas más básicas que engloban tres criterios: El nombre del archivo/directorio, el usuario que es dueño de éste y (a veces) el grupo al que pertenece el susodicho. Son criterios simples que generalmente bastan para satisfacer la mayoría de las necesidades; criterios que usaríamos de la siguiente forma:

Para buscar un archivo por nombre podemos recurrir a diferentes medios, si bien todas las búsquedas por nombre están basadas en el criterio -name. En ejemplo de una búsqueda muy básica, sería la búsqueda de un archivo llamado texto.txt que se realizaría desde el directorio raíz:

find / -name "texto.txt"

La búsqueda por nombre va más allá de ésto... es decir que no solo se limita a buscar una cadena de texto fija; podemos jugar con diferentes rangos y valores para adaptar ese nombre a diferentes situaciones; por ejemplo:

Para buscar nombres que empiecen por a:
find / -name "a*"
Para buscar nombres que terminen en una letra minúscula
find / -name "*[a-z]"
Si queremos aplicar lo mismo que antes pero para cualquier letra:
find / -name "*[a-Z]"
Podemos usar rangos numéricos si lo deseamos:
find / -name "[0-9]*.txt"

Además -name posee un "hermano" llamado -iname que no realizaría distinciones entre mayúsculas y minúsculas, con lo que dependiendo para qué búsquedas puede resultarnos más útil que el criterio original.

Tal y como hemos visto antes, también tenemos la opción de buscar por usuario y grupo; aunque obviamente para ello habría que conocer bien esos conceptos... Una buena ayuda para saber a qué usuario y grupo pertenecen los archivos y directorios es el comando ls -la, pero esto ya depende de las preferencias de cada uno. A sabiendas de los usuarios y grupos existentes, ya seríamos capaces de realizar búsquedas en condiciones en base a dichos parámetros, con lo que si por ejemplo deseásemos buscar todos los archivos pertenecientes al usuario ivan tendríamos que recurrir al criterio -user tal que así:

find / -user ivan

En cambio si deseásemos encontrar todo lo que perteneciese al grupo con el mismo nombre, tendríamos que usar el criterio -group:

find / -group ivan

Obviamente todo esto es perfectamente combinable entre sí, y mediante estos pequeños criterios básicos podemos hacer búsquedas muy completas y potentes; por ejemplo:

find /var -name "[a-n][0-9]*.sh" -user ivan -group test


Búsquedas inversas y búsquedas por tipo

Las búsquedas básicas nos sacarán de la mayoría de los atolladeros, pero hay un par de criterios que aunque no son especialmente usados, son casi tan útiles como los anteriormente mostrados: Las búsquedas por tipo y las búsquedas inversas. El primer tipo de búsqueda se realiza usando el criterio -type seguido del tipo de archivo que deseamos encontrar; es más podemos decirle que lo que queremos encontrar es un directorio; he aquí un ejemplo:

find / -name "*[a-Z]" -type f

En este caso le hemos especificado que queremos encontrar únicamente archivos; existen obviamente más tipos; aunque hay muchos tipos de archivo, los más populares en éstas búsquedas serían:

Nuestras búsquedas se van haciendo progresivamente más eficientes, ¿pero que pasaría si quisiésemos que buscase exactamente lo opuesto a lo especificado en un criterio? ¿Es decir que quisiésemos buscar por ejemplo todo aquello que no fuese del usuario ivan o que no fuese un fichero regular? Afortunadamente contamos con un criterio muy sencillo llamado -not que hace exactamente eso; CUIDADO: Dicho criterio -not únicamente sería válido para el siguiente criterio, es decir que si hubiesen dos criterios después del -not, éste únicamente afectaría al primero de ellos; es decir que si quisiésemos que la búsqueda inversa afectase a todos los criterios, habría que especificar -not en cada uno de estos. Una búsqueda inversa de ejemplo sería:

find /etc -name "[a-b]*[0-5]" -not -type d

Aquí diríamos que todo aquello que se buscase a partir del directorio /etc todo aquello que empezase por a o b, terminase entre el 0 y el 5 y que NO fuese un directorio.


Usando valores númericos para búsquedas avanzadas

Aunque los criterios básicos/intermedios nos otorgan un enorme poder de búsqueda, a veces esto no es suficiente y necesitamos más capacidad de búsqueda; búsquedas que ya están relacionadas con tamaños de archivos o con cantidad de minutos/días... Es decir, relacionadas con argumentos numéricos. Si bien es cierto que esto puede parecer que sea una búsqueda muy poco práctica,  en más de una ocasión estas búsquedas me han resultado enormemente útiles, especialmente para buscar ficheros muy grandes o muy pequeños... Aún así, antes de empezar a trabajar con los criterios usados para este tipo de búsquedas, es importante tener claros tres conceptos que, aunque a primera vista pueden parecer muy simples, nunca está de más tenerlos claros.

  • +número: Por ejemplo +36; esto significa que la búsqueda tendrá en cuenta todo aquello que sea mayor a dicho número.
  • -número: Por ejemplo -5; esto significa que la búsqueda tomará en cuenta aquello que sea menor a este número.
  • número: Por ejemplo 10; aquí únicamente se mostrará aquello que encaje exactamente con dicho número.

¿Sencillo cierto? Ahora que se tienen claro estos tres pequeños conceptos podríamos empezar a trabajar con las búsquedas relacionadas con números; números que generalmente se asocian a dos tipos de criterio: Tiempo desde que se modificó/leyó el fichero y tamaño de éste.

Para buscar un archivo por su tamaño habría que tener en cuenta que find únicamente es capaz de reconocer las siguientes unidades de medida:
  • k: Kilobytes
  • c: bytes
  • w: 2 bytes
  • b: 512 bytes

Al existir pocas unidades de medida, las he mostrado todas, si bien las más prácticas serían las búsquedas por kilobytes para la mayoría de archivos "comunes" y por bytes para archivos muy muy pequeños. Las otras dos unidades de medida, si bien es bueno saber que existen, no son apenas usadas en la actualidad. Cualquier búsqueda relacionada con el tamaño de un archivo se realiza mediante el criterio -size; criterio que podemos usar para que especificar archivos de un tamaño exacto o de un tamaño mayor/menor del especificado, otorgándonos cierta flexibilidad. Por ejemplo:

find / -size +100000k
También podemos hacer búsquedas dentro de un cierto rango de tamaño
find / -size +100000k -size -150000k

Por otro lado también podemos buscar archivos que hayan sido leídos y/o modificados recientemente gracias al uso de argumentos numéricos; esto es especialmente útil cuando se quieren realizar búsquedas delicadas en las que queramos saber si se ha leído o modificado un archivo en un periodo de tiempo en el que supuestamente no debería haber pasado. Aquí se usan diferentes criterios dependiendo de nuestras necesidades, si bien en este caso todos ellos son útiles a su manera:

  • -atime: Número de días desde que se ACCEDIÓ al fichero por última vez.
  • -mtime: Número de días desde que se MODIFICÓ el fichero por última vez.
  • -amin: Número de minutos desde que se ACCEDIÓ al fichero por última vez.
  • -mmin: Número de minutos desde que se MODIFICÓ el fihcero por última vez.
Si bien los criterios de búsqueda basados en minutos ofrecen una mayor flexibilidad que el de días, dependiendo de los rangos de tiempo en los que nos movamos, pueden ofrecernos resultados muy interesantes; al igual que con el tamaño podemos usar valores fijos o combinados con + o -, con lo que podemos realizar búsquedas tan interesantes como las siguientes:

Para ficheros modificados hace menos de 5 minutos podríamos recurrir al siguiente ejemplo:
find / -mmin -5
Si queremos ficheros accedidos hace menos de 1 día y modificados hace menos de 30 minutos podríamos recurrir a esta sentencia:
find / -atime -1 -mmin -30
También podemos hacer búsquedas entre dos intervalos de tiempo para ser muy precisos:
find -mmin +10 -mmin -20

Como podéis ver las posibilidades que ofrecen estos criterios numéricos son muy amplias, solo basta con jugar con éstos para adaptarlos lo mejor posible a nuestras búsquedas.


Ejecución de comandos

No puedo finalizar este post sin mencionar la ejecución de comandos; aquel punto tan "delicado" que he comentado en mi explicación inicial; imaginemos que hemos hecho una búsqueda muy avanzada y precisa ¿Qué hacemos después? ¿Usamos los comandos deseados sobre cada uno de ellos? NO. Eso sería dejar de lado la potencia que nos ofrece find. Tras poner todos los criterios necesarios para encontrar nuestros preciosos archivos, opcionalmente, podemos decidir qué hacer con ellos tras encontrarlos; existen diferentes acciones posibles (generalmente comandos que puede ejecutar find) si bien mi acción favorita es -exec ya que nos permite ejecutar cualquier comando como sin nos encontrásemos dentro de un shell. Cualquier comando lanzado mediante -exec tendría este aspecto:

-exec comando {} \;

{} Representaría el resultado obtenido del comando find mientras que los caracteres \; representarían el "fin" de la acción o comando a ejecutar tras la búsqueda... ¿Qué usos prácticos se le puede dar a esto? Esto depende de nuestras necesidades e imaginación, pero he aquí algunos ejemplos:

Si deseásemos eliminar archivos regulares que tuviesen un tamaño excesivamente grande podríamos escribir este comando:

find / -size + 1000000k -type f -exec rm -f {} \;

Si deseásemos consultar el contenido de archivos que hayan sido modificados recientemente, que no excedan los 1000k de tamaño y queremos tener la certeza de que NO son directorios, este sería el comando:

find / -mmin -60 -size -1000k -not -type -d -exec cat {} \;


Como podéis observar find es una herramienta increíblemente potente y polivalente que con unos pocos criterios nos puede sacar de grandes apuros; el único límite en nuestras búsquedas, sería el impuesto por nuestra imaginación.

Espero que os haya resultado útil.

Saludos.

viernes, 26 de febrero de 2016

Cómo registrar todos los comandos introducidos en Linux

El control de lo que ocurre en nuestro equipo es uno de los puntos que más nos preocupa a la mayoría de los que poseemos un ordenador; especialmente cuando dicho ordenador es usado por más personas aparte de nosotros... Por mucho que confiemos en que no van a hacer nada malo en nuestra ausencia, siempre tenemos esa duda en nuestro interior... ¿Y si esa persona rompe algo? ¿Y si introduce un "comando fatal"? ¿Cómo podemos demostrar qué alguien ha roto algo en un momento determinado? Los logs incluidos por defecto en Linux son extremadamente útiles, pero por sí solos no son lo suficientemente detallados como para decirnos con exactitud lo que se ha hecho... Es por ello que hoy vengo con una pequeña solución que podemos usar para solventar este pequeño problema; dicha solución se llama snoopy.

Snoppy_portada

Existen otras alternativas que pueden sernos útiles también y que no requieren instalar nada, tales como el uso del comando history o la consulta del fichero oculto .bash_history, dentro de la carpeta personal de cada usuario, pero no registran absolutamente todo y además la información puede quedarse dispersa... Por ejemplo podemos tener actividad de root en un lado mientras que en otro lado la actividad de un usuario normal... además ninguno de los dos registra fechas, con lo que aún registrando absolutamente todo no podemos saber a qué hora se hizo cada cosa, siendo muy complicado tener pruebas concluyentes. Es por eso que con el uso de snoopy tendremos más fiabilidad ya que registra la fecha ya la hora en que se ejecutó el comando y el usuario que lanzó el susodicho...

La instalación y uso de esta utilidad es extremadamente sencillo; snoopy no se encuentra instalado por defecto en el sistema operativo, pero se instala con extremada facilidad mediante el uso de los repositorios:

apt-get install snoopy

Dicho paquete incluye la instalación de una librería llamada ld.so.preload, la cual se encarga de registrar las actividades realizadas en nuestro equipo; la cuestión está en que al ser una librería "importante" requerirá nuestra confirmación mostrándonos un dialog.

validacion_lib

Obviamente tendremos que seleccionar el sí para poder monitorizar adecuadamente toda la actividad; unos segundos después de la instalación, el sistema estaría monitorizando TODA la actividad realizada por cualquier usuario, almacenando dicha actividad en el fichero de log /var/log/auth.log; es decir que no crea una fichero de log nuevo sino que aprovecha uno existente. El objetivo de dicho fichero de por sí es registrar toda actividad relacionada con acciones de login, intentos de conectar por ssh, etc... Es decir, que tiene una gran cantidad de líneas aparte de las que añade snoopy de por sí, es por ello que para hacer una consulta eficiente en dicho fichero, habría que recurrir al siguiente comando;

tail -n 100 -f /var/log/auth.log |grep snoopy

Esto de por sí ya sería suficiente para poder ver en tiempo real todo comando introducido, informándonos además de detalles importantes tales como el usuario, la fecha y la hora... Un ejemplo del resultado mostrado sería la captura de a continuación:


Para saber quien ha sido el que ha ejecutado el comando habría que ver el uid (user id) del que ha ejecutado la orden; por ejemplo el uid de root sería el 0.

El único "problema" de esta solución basada en snoopy, es que auth.log irá creciendo a un ritmo vertiginoso; llegando a poder ocupar prácticamente la totalidad del sistema con sus consecuencias (disco saturado, servicios parados que no pueden arrancar, etc...), con lo que es necesario recurrir a algún método que evite dicha catástrofe. El método más sencillo y práctico sería el uso de logrotate para que auth.log rotase diariamente y guardase únicamente la actividad de los 7 últimos días: auth.log correspondería a los logs de hoy, auth.log,1 a los de ayer y así sucesivamente hasta 7... Con esto guardaríamos la información de la última semana al mismo tiempo que evitaríamos el saturamiento del sistema operativo.

Eso se consigue editando el fichero /etc/logrotate.d/rsyslog; el cual generalmente ya tiene reglas que trata este fichero; pero no siempre. Es por ello que es mejor pecar de prevenido que curar y revisar este archivo. En caso de aparecer la línea /var/log/auth.log, debería de ser capaz de ser capaz de hacer la rotación automática; aún así yo recomiendo borrarla y añadir el siguiente contenido final del fichero:

  1. /var/log/auth.log
  2. {
  3. rotate 7
  4.         daily
  5.         notifempty
  6.         delaycompress
  7.         compress
  8.         postrotate
  9.                 invoke-rc.d rsyslog rotate > /dev/null
  10.         endscript
  11. }

Gracias a esta pequeña medida no solo tendríamos registrada toda la actividad de la última semana sino que tendríamos la certeza de que evitaremos cualquier problema de espacio en el disco duro a medio/largo plazo.

Espero que os haya resultado útil.

Saludos.

miércoles, 24 de febrero de 2016

Postgresql, una alternativa a mysql en Linux

Hoy quiero venir con algo ligeramente distinto a lo que suelo traeros; generalmente suelo centrarme en temas más referentes a shells, redes o seguridad, pero hoy quiero veniros con un post orientado a la bases de datos. Hace ya tiempo hice referencia al montaje de un servidor LAMP y a la securización de éste; LAMP estaría compuesto por: Linux, Apache, Mysql y PHP; servicios muy famosos usados en todo el mundo. La cuestión está en que el mundo no está compuesto únicamente por estas herramientas y siempre hay otras alternativas como Nginx para un servidor web por ejemplo... Es por ello que hoy quiero traeros una alternativa a Mysql: postgresql.

postgresql_portada

Para empezar creo que es necesario hacer una pequeña explicación sobre las diferencias entre una base de datos y otra, pues aunque ambas son de código abierto, existen bastantes diferencias entre ellas. La primera y más fundamental es el tipo de licencia sobre la que están distribuidas: Mysql está distribuida bajo una licencia copyleft, es decir que puede ser distribuida libremente siempre y cuando se preserven los mismos derechos que los de la versión original... En otras palabras que requiere que el código del programa que trabaje con mysql sea liberado; cosa que por ejemplo para algunas empresas puede ser complicado e incluso contraproducente... Eso no significa que la licencia sea buena o mala sino que es una licencia que se encuentra en sintonía con la filosofía del software libre. Postgresql en cambio tiene una licencia más abierta y flexible que puede adaptarse a más entornos sin tener que preservar tantos derechos como Mysql (para bien o para mal).

Obviamente también existen diferencias técnicas: Mysql trabaja muy bien con php y es realmente eficiente a la hora de realizar consultas sql sencillas... En cambio cuando se quiere trabajar con un gran volumen de tablas y se quiere apostar más por la integridad de la base de datos en vez de por la eficiencia de las consultas sql, se suele optar por postgresql. Ambas son grandes opciones, cada una con sus virtudes y defectos, y si bien a nivel técnico ambas van mejorando a pasos agigantados, la filosofía de cada una sigue siendo completamente diferente la una de la otra.

Ahora que ya tenemos cierta idea de lo que nos aporta postgresql, pasemos al uso de éste. Como toda base de datos basada en Linux, postgresql no se halla instalado en Linux, pero al estar incluido en los repositorios oficiales no tendremos problemas instalándolo, con lo que la instalación sería tan sencilla como escribir:

apt-get install postgresql

Tras un rato tendríamos la base de datos instalada, pero habrían dos problemas: El primero es que nadie puede conectarse a la base datos a excepción del propio equipo en el que se ha instalado el software, cosa muy poco práctica, especialmente para gestionar la base de datos remotamente. La otra pega es que por defecto la base de datos está diseñada para soportar "solo" 100 conexiones simultáneas; a partir de allí la base de datos se ralentizaría e incluso se podría llegar a detener dicha base de datos debido a la sobrecarga de conexiones. Es por ello que es recomendable poner postgresql "a punto" antes de empezar a usarlo. Para dicha puesta a punto es necesario dirigirse a la carpeta de configuración de postgresql, la cual es: /etc/postgresql/(versión)/main/; al habernos descargado para este caso en concreto la versión 9.4, nos moveremos a dicha carpeta mediante el comando cd de la siguiente forma:

cd /etc/postgresql/9.4/main/

Este directorio está compuesto por 6 ficheros, de los cuales dos, nos interesan especialmente: pg_hba.conf y postgresql.conf. El primero es el encargado de gestionar qué ips pueden conectarse a la base de datos; si le echamos un vistazo veremos que solamente tiene tres lineas útiles (el resto son comentarios):

  1. local   all             all                                     peer
  2. host    all             all             127.0.0.1/32            md5
  3. host    all             all             ::1/128                 md5

La primera línea se encarga de abrir puertos en el servidor y no requiere que la modifiquemos ni la borremos; las otras dos son las líneas que especifican qué ips pueden conectarse. Por temas de gestión es recomendable no borrar esas líneas, pero sí que es recomendable añadir algunas líneas nuevas para evitar problemas. En mi caso en concreto he añadido una línea para que todos los de la red local puedan acceder a la base de datos; para ello primero habría que conocer la estructura con la que trabajan dichas líneas:

host base_de_datos usuario ip/mascara método_de_autenticación

En caso de querer hacer referencia a "todos", es decir a todas las bases de datos o que todos los usuarios asociados con postgresql puedan acceder, habría que escribir all. Mi línea en concreto sería la siguiente:

host    all             all             192.168.1.0/255.255.255.0                 md5

Ahora que la base de datos es más "accesible", habría que optimizarla para que pueda soportar más conexiones a la vez... Para ello lo primero que tenemos que saber es saber con cuanta memoria RAM trabajamos para hacer nuestros calculos; no es lo mismo trabajar con un equipo de 8 GB de RAM que con uno de 16... Para conocer la cantidad total de memoria RAM que dispone nuestro equipo podemos hacer uso del comando free -m.

Supongamos que contamos con 8 GB de ram. Ahora nos dirigiríamos al fichero postgresql.conf y editaríamos los siguientes parámetros:

  • listen_addresses: La base de datos está diseñada para "escuchar" únicamente en localhost, aquí habría que poner la ip de la interfaz de red que queremos que reciba las conexiones del resto de lugares.
  • max_connections: Aquí pondríamos el número máximo de conexiones. Cada conexión requiere consumir cierta ram del equipo, con lo que es importante no "pasarnos", si bien realizar un calculo preciso es complicado; se pueden buscar herramientas online que juegan sobre seguro o se pueden ir probando diferentes cantidades hasta dar con la adecuada.
  • shared_bufers: Este valor indica cuanta ram está reservada para el arranque de postgres; aquí no es necesario poner un valor extremadamente alto, si bien el valor por defecto (24 MB) , se puede quedar corto, pues puede que no sea capaz de arrancar. El valor ideal es poner el 10% de la memoria RAM total en este parámetro (he ahí el motivo por el que es conveniente saber de cuanta RAM total disponemos).
  • work_mem: También conocido como memoria de trabajo, especifica la memoria reservada para tareas como la ordenación de tablas o la ejecución de consultas. Generalmente en servidores "normales" se suele asignar un 2% de la memoria RAM total, pero en caso de quedarse corta se pueden asignar hasta 4.
  • effective cache size: Indica cuanta memoria máxima cachear para postgres; al ser un valor que influye en la caché, se pude asignar tranquilamente la mitad de la RAM total.

Con estos valores, y suponiendo que tenemos un equipo con la ip 192.168.1.5 con un capacidad de 8 GB de RAM, tendríamos el siguiente resultado:

  1. listen_addresses = 'localhost, 192.168.1.5'
  2. max_connections200
  3. shared_buffers = 800MB
  4. work_mem=160MB
  5. effective cache size=4GB

Si tuviesemos "miedo" a forzar demasiado los parámetros y quisiesemos un método automatizado que, si bien no le saca todo el partido a la base de datos, es más seguro, podemos recurrir a webs tales como http://pgtune.leopard.in.ua/ que te "tunean" la base de datos para dejartela a medida; eso sí, ellos mismos admiten que sus parámetros son recomendaciones.  Para aplicar los cambios habría que reiniciar el servicio mediante el comando:

/etc/init.d/postgresql restart

Con las versiones más nuevas, este proceso es suficiente para optimizar nuestra base de datos, pero las versiones previas a la 9.4, tienen un problema con la gestión de la memoria y no dejarán que postgres arranque... Si vamos al fichero /var/log/syslog, veremos un error parecido al siguiente:

CETFATAL: could not create shared memory segment: Argumento inválido
CETDETAIL: Failed system call was shmget(key=5432001, size=4294967296, 03600).
CETHINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 3495149568 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

Esto significa que la memoria que queremos usar excede la capacidad que soporta nuestro kernel, impidiendo que arranque postgres. Afortunadamente esto se puede solucionar mediante la ayuda de sysctl; mediante dicho comando modificaremos dos valores: shmmax y shmall; shmmax tendrá que tener el mismo valor que el indicado en el valor size del fichero /var/log/syslog, mientras que el valor shmall tendría que ser dicho valor dividido entre 4096 (4KB); con lo que editaríamos ambos valores de la siguiente forma en el fichero /etc/sysct.conf:

  1. kernel.shmmax=4294967296
  2. kernel.shmall=1048576

Para aplicar los cambios tendríamos que escribir el siguiente comando en la consola:

sysctl -p

Gracias a dicho cambio, ahora seríamos capaces de iniciar postgresql sin impedimentos, pudiendo disfrutar de una base de datos a pleno rendimiento, eso sí; manejar postgresql desde la consola puede ser muy dificultoso, con lo que es recomendable usar herramientas gráficas tales como pgadmin (la oficial de postgresql) para facilitarnos la vida. Dicha herramienta es muy útil pues podemos usarla tanto en entornos Windows como Linux.

Espero que os haya resultado útil.

Saludos.