Información blog

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

lunes, 25 de abril de 2016

Paquetes snap Ubuntu ¿Una moda que viene para quedarse?

Hola a todos, hoy os vengo a hablar sobre un nuevo concepto que está dando bastante que hablar en el mundo del software libre: Los paquetes snap. Estos paquetes vienen incluidos en la nueva y esperadísima versión de Ubuntu: 16.04 LTS, la cual ha salido oficialmente a la luz hace muy pocos días. Esta nueva versión trae relativamente pocos cambios de cara al usuario final, (al menos a grandes rasgos sin incluir los cambios de los entornos gráficos), pero sí que se han destacado varias nuevas características a nivel profesional o a nivel avanzado, tales como el uso del polémico sistema de ficheros zfs, o el uso de containers docker para tareas dirigidas al servidor o a la nube... Aún así el objetivo de hoy sería centrarnos únicamente en estos nuevos paquetes, pues han aparecido prácticamente de la nada y están preparados para "convivir" con los paquetes que se han estado usando toda la vida en los sistemas basados en Debian: Los paquetes .deb.

snap_ubuntu

Hasta el momento lo que se ha hecho siempre para instalar un nuevo programa ha sido usar gestores de paquetes cómodos, como pueden ser el gesto de paquetes Synaptic (en entornos de escritorio) o apt-get para los entornos de consola; operaciones que simplemente descargaban unos paquetes .deb y los instalaban automáticamente uno a uno sin necesidad de que nosotros bajásemos los paquetes .deb manualmente para instalarlos uno a uno mediante dpkg

El motivo principal de este cambio tan radical, es que se desea agrupar TODAS las dependencias de un programa dentro de un mismo paquete, cosa que con los .deb no ocurre... Es decir que por ejemplo a la hora de instalar firefox, necesitamos también descargarnos una serie de dependencias que son necesarias para que el programa se instale y/o funcione; este problema se evade mediante los paquetes snap; pues aquí todo viene agrupado dentro del mismo paquete, evitando posibles carencias.

Esto tiene como principal ventaja la comodidad que genera el hecho de tener todo lo necesario dentro del mismo paquete; además de que gracias a snap, los paquetes descargados y instalados se usarán única y exclusivamente para el programa en cuestión; haciendo que el sistema sea (en teoría) más difícil de "romper" en caso de instalar algo que no debamos.

Aún así hay muchos detractores de este tipo de paquetes, pues si bien eso en teoría hace que sea todo más modular, también hace que los paquetes que instalemos sean más difíciles de controlar, pues cada programa tendrá sus paquetes, con su versión de éstos y con sus vulnerabilidades; convirtiéndolo en un sistema con muchas más exposiciones. Además también tiene el inconveniente de que este tipo de instalación ocupa más espacio en el disco duro que mediante paquetes .deb, pues con los paquetes "originales" habían programas que compartían las mismas librerías, haciendo que no fuese necesario instalarlas de nuevo; si bien esto es un mal menor, ya que hoy en día es raro encontrar discos duros con capacidades menores a 1 Terabyte.

Este nuevo y singular paquete tiene también su propio gestos, pues es una paquetería completamente independiente del resto y como tal necesita su propio software para gestionar dichos paquetes. Dicho software es denominado Snap Package Manager, si bien de forma abreviada se llama (valga la redundancia) snap. Dicho gestor es bastante diferente al resto de gestores, pero hay algunas funciones básicas que tienen un gran parecido al resto; funciones que serían las que más usásemos que serían:


  • find: Listaría todos los paquetes snap que podemos instalar. De momento no existen demasiados, pero dependiendo de lo popular que se vuelva este gestor (que perteneciendo a Ubuntu, supongo que será exitoso) irá ampliando su variedad.
  • install: Instala uno de los paquetes que aparecen dentro del listado mostrado en find; cumple una función muy parecida a apt-get install , pero en este caso la interacción se realiza con snap.
  • list: Es parecido a find, con la diferencia de que hace un listado de únicamente los paquetes snap que tenemos instalados. Sin duda muy útil para mantener cierto control sobre nuestro sistema.
  • remove: Elimina un paquete snap que tengamos instalado. Sería parecido a apt-get remove, pero aplicado a paquetes snap.

Es decir que por ejemplo para instalar nmap (que tiene paquete snap) habría que hacer:

snap install nmap

De momento es demasiado pronto para sacar conclusiones sólidas, pero podemos deducir que estos paquetes darán mucho que hablar y que si bien giran todo tipo de opiniones en torno a estos paquetes, es obvio que Ubuntu apostará muy fuerte por ello; al menos durante un tiempo...

Espero que os haya resultado interesante.

Saludos.

miércoles, 20 de abril de 2016

Cómo habilitar y deshabilitar un firewall con Asterisk

Hola a todos, hoy quiero veniros con un articulo al que en mi opinión se le puede sacar bastante partido; ya sea a nivel práctico o a simple nivel de curiosidad. Imaginemos que tenemos un servidor con un acceso bastante restringido en el que tenemos que habilitar y deshabilitar un firewall cada dos por tres para tareas de mantenimiento (o simplemente se quieren cambiar algunas reglas que siempre serán las mismas). Esto requiere tener que entrar al servidor físicamente o vía ssh, loguearse, ponerse privilegios de super-usuario, deshabilitar o cambiar el firewall etc... Esto una vez no importa, pero cuando ya la tarea se torna repetitiva esto puede ser un verdadero fastidio... Es cierto que el proceso en sí no tiene que ser necesariamente complicado ¿Pero para qué complicarnos la vida cuando podemos hacer todo pulsando uno o dos botones? Es por eso que hoy os quiero venir con un método muy sencillo basado en Asterisk, que creo que más de uno encontrará interesante.

firewall_asterisk_bash

Aunque en más de una ocasión he hablado sobre esta tecnología; para aquellos que aún no la conozcan les diré que es un programa de software libre que hace las veces de centralita (PBX), capaz de comunicarse por métodos convencionales dentro de este mundillo (como RDSI) o por un método más usado y moderno, llamado voz ip, que haría la comunicación de voz por red (algo parecido a lo que se hace hoy en día con Skype). En este caso nos centraríamos en este último método de comunicación, pues todas las acciones se realizan a nivel de red y aquí sí que podemos ejercer cierto control tanto sobre el software como sobre el servidor. Para ello obviamente necesitaremos instalar Asterisk, pues es una herramienta de terceros que no está instalada por defecto en el sistema, si bien está incluida en los repositorios. Aquí habría que tener en cuenta qué uso se le quiere dar a Asterisk pues si se le quiere dar un uso profesional (es decir, se quieren hacer más cosas aparte de la gestión del firewall), lo más recomendable es descargar los paquetes asterisk y libpri a mano para después compilarlos e instalarlos a mano mediante el famoso make. En este caso en concreto no nos hace falta ser muy escrupulosos, así que optaremos por el método rápido e instalaremos Asterisk directamente desde los repositorios mediante apt-get.

apt-get install asterisk

La instalación es automática y no requerirá confirmación alguna así que no habría que preocuparse. Lo que sí que habría que tener en cuenta es que la instalación creará un nuevo usuario llamado Asterisk, usuario que gestionaría (de forma automática) todas las llamadas realizadas en Asterisk y todas las tareas relacionadas con la comunicación voz ip. El problema es que este usuario no tiene permisos de super-usuario, y en este caso al estar manejando algo tan delicado como el cortafuegos, necesita convertirse en super-usuario; esto es tan sencillo como añadir dicho al fichero /etc/sudoers... Pero en este caso vamos a ponerle a asterisk unos privilegios limitados dentro del colectivo de super-usuario; La línea que habría que añadir a dicho fichero sería:

asterisk ALL=(ALL)NOPASSWD:/sbin/iptables

En este caso en concreto le hemos dicho que Asterisk no requiera pedir contraseña al hacer sudo, pero que únicamente pueda ejecutar iptables. El motivo de esta restricción es simple: Queremos que lo único que pueda hacer asterisk como sudo es el uso de iptables, pues el darle acceso al resto podría ser contraproducente e incluso peligroso. Eso no significa que no pueda hacer nada de lo que podía hacer antes; simplemente hemos hecho que el único permiso "adicional" que tiene es el uso de /sbin/iptables.

Ahora que Asterisk es lo suficientemente "poderoso" necesitamos prepararlo para habilitar y deshabilitar el firewall... Explicar en profundidad el corazón de Asterisk es increíblemente complicado, pues requeriría entender muchos conceptos y realizar muchísimas explicaciones, con lo que vamos a enfocarnos únicamente en dos ficheros en concreto alojados en /etc/asterisk: sip.conf y extensions.conf. El primero representaría los "teléfonos" que se conectarían a Asterisk mediante un protocolo denominado protocolo SIP, mientras que el segundo representaría el comportamiento de estos: es decir qué hacer en caso de que un teléfono X marque unos dígitos determinados. Estos ficheros ya tienen de por sí unas configuraciones por defecto y una serie de líneas y comentarios (líneas que no tienen valor alguno a nivel de funcionalidad) que nos van a suponer una molestia, con lo que en mi opinión lo mejor que se puede hacer es dejarlos vacíos y rellenarlos.

Lo primero que haríamos sería crear un teléfono es sip.conf; dicha creación se basaría en dos partes: La creación de unos parámetros generales, ya la creación de unos parámetros específicos para el teléfono. En este caso voy a poner la configuración del sip.conf para luego explicar los parámetros más relevantes:

  1. [general]
  2. context=default
  3. port=5060
  4. bindport=5060
  5. bindaddr=192.168.1.7
  6. disallow=all
  7. allow=alaw
  8. nat=never
  9. language=es
  10. [1001]
  11. type=friend
  12. host=dynamic
  13. username=1001
  14. secret=100112341001
  15. context=cortafuegos

A modo de recomendación personal, lo mejor es copiar y pegar todo el contenido y modificarlo a nuestro gusto, pues hay varios parámetros que podemos personalizar:


  • port: Puerto de escucha de Asterisk para la comunicación SIP; el puerto de escucha por defecto usado para estas comunicaciones el 5060 y es recomendable no cambiarlo. Obviamente también hay que tener cuidado para que el servidor no bloquee dicho puerto, o que al menos no nos lo bloquee a nosotros.
  • bindport: Cumple la misma función que port, pero es más "estable" que port a nivel interno. Si bien hacen lo mismo, lo mejor es tener incluidos ambos valores: port y bindport.
  • Bindaddr: Aquí podemos decir a qué ip se van a conectar los "teléfonos"; esto es especialmente útil si se tienen varias tarjetas de red o ips virtuales, ya que gracias a ésto especificamos que únicamente se pueden conectar a dicha ip. A nivel de seguridad de es un valor IMPRESCINDIBLE.
  • Username: El nombre de usuario que tiene que usar el "teléfono" para registrarse. Dicho nombre de usuario también sería el número que habría que marcar si quisiésemos llamarle (cosa que en este caso no haría falta hacer, pero que es útil saber).
  • Secret: Contraseña especifica para dicho teléfono para que éste se registre en Asterisk.
  • Context: Otro valor de gran importancia llamado técnicamente como contexto; aquí se dice a qué "sección" de extensions.conf pertenece. No es lo mismo que un teléfono perteneciente a la sección X llame al número 1234 que lo haga uno que perteneciese al contexto Y. En este caso en concreto el teléfono pertenecerá al contexto cortafuegos.

Tenemos preparada la configuración del teléfono, faltaría preparar el comportamiento de éste; Es decir habría que decir qué hará en caso de marcar un número determinado. Esto, tal y como he comentado antes, se hace en extensions.conf, y el contenido de este es llamado técnicamente como dialplan. Aquí se pueden crear verdaderas maravillas a nivel técnico, pero en este caso en concreto vamos a optar por una solución sencilla y centrada única y exclusivamente en el cortafuegos. El contenido de este fichero sería:

  1. [general]
  2. static=yes
  3. writeprotect=no
  4. autofallthrough=yes
  5. clearglobalvars=no
  6. priorityjumping=no
  7. [cortafuegos]
  8. exten => 1,1,NoOp("SE ACTIVA EL CORTAFUEGOS")
  9. exten => 1,n,System(/usr/bin/firewall start)
  10. exten => 1,n,Hangup()
  11. exten => 2,1,NoOp("SE DESACTIVA EL CORTAFUEGOS")
  12. exten => 2,n,System(/usr/bin/firewall stop)
  13. exten => 2,n,Hangup()

Aquí los valores incluidos en general no nos interesan, pues son valores generales, valga la redundancia, que simplemente se ponen para establecer una serie de políticas. Lo que en este caso nos interesaría sería el contexto que va entre los caracteres [ ], llamado cortafuegos; contexto el que decimos qué hacer. En este caso únicamente hacemos que haga algo en caso de marcar los números 1 o 2.  El marcar estas teclas harán tres acciones:

  1. Mostrar un mensaje en Asterisk (interno).
  2. Realizar una acción llamada System, encargada de ejecutar comandos y/o scripts del sistema operativo.
  3. Colgar la "llamada".

La primera y la tercera línea serían iguales, mientras que la segunda, la más importante, ejecutaría el script /usr/bin/firewall, pero dependiendo de qué dígito hayamos marcado mandaría el parámetro start o stop a éste. Obviamente dicho script sería de nuestra invención y haría lo que nosotros deseásemos. Después de modificar los ficheros atrás comentados, habría que aplicar los cambios... Hay varios métodos para aplicar los cambios (algunos más sutiles que otros) pero requieren ciertos conocimientos de Asterisk con lo que optaremos por el método más "clásico" y brusco: Reiniciar el programa:

/etc/init.d/asterisk restart

A nivel de servidor únicamente faltaría una cosa más: La preparación del script que queremos que sea ejecutada por los dígitos 1 y 2 del contexto "cortafuegos"; en este caso /usr/bin/firewall . Esta parte es la más abstracta de todas, pero a modo de demostración podríamos hacer que el script fuese algo como esto:

  1. #!/bin/sh
  2. case "$1" in
  3.         start)
  4.                 #CERRAMOS TODO A EXCEPCION DE LOS PUERTOS JUSTOS Y NECESARIOS
  5.                 sudo /sbin/iptables -A INPUT -p udp --dport 5060 -j ACCEPT
  6.                 sudo /sbin/iptables -A INPUT -s 192.168.1.2 -p tcp --dport 22-j ACCEPT
  7.                 sudo /sbin/iptables -A INPUT -j DROP
  8.         ;;
  9.         stop)
  10.                 #DEJAMOS PASO ABIERTO A TODO
  11.                 sudo /sbin/iptables -F
  12.         ;;
  13. esac
  14. exit 0

Este script es muy simple pero perfectamente válido; si bien obviamente puede modificarse para adaptarse a necesidades algo más "realistas".

Con esto tendríamos la parte del servidor hecha pero... ¿Cómo enviamos esos dígitos al servidor? ¿Realmente es necesario usar un teléfono (que tendría que ser un teléfono ip) únicamente para esto? Gracias a las tecnologías de hoy en día, podemos descargarnos un softphone que hará de teléfono virtual y que hará que no sea necesario usar teléfono físico alguno. Hay varios softphones disponibles hoy en día aunque los más populares serían Ekiga y X-Lite. En este caso optaré por Ekiga, pues la gran ventaja que tiene es que puede usarse tanto en Windows como en Linux y que puede descargarse en la página oficial. También es importante tener en cuenta de que el servidor y el softphone/teléfono ip tienen que estar en la misma red local, ya sea real o virtual; es decir que se tiene que ser capaz de "alcanzar" la ip en la que Asterisk está esperando a que nos conectemos.

Con la herramienta descarga e instalada, únicamente habría que ir a Editar --> Cuentas y dentro de dicha sección habría que ir a Cuentas --> Añadir cuenta SIP (una cuenta que usaría el mismo protocolo que el que hemos usado en el servidor). Ahí habría que poner el nombre de la cuenta, el nombre de usuario y el usuario de autenticación, que constaría del username puesto en sip.conf, el servidor de registro, que sería la ip puesta en el parámetro bindaddr de la configuración general de sip.conf y la contraseña, que sería el parámetro secret de la cuenta. Los valores son muy intuitivos pero he aquí una pequeña ayuda visual:

Ekiga_asterisk

Con estos valores puestos, simplemente habría que aplicarlos y ya tendríamos nuestro softphone activado y operativo; únicamente habría que marcar los dígitos 1 o 2 y darle al botón de llamar para poder disfrutar de esta curiosa, pero útil forma de activar y desactivar un cortafuegos a nuestra conveniencia.

Saludos.

martes, 12 de abril de 2016

Fichero nsswitch.conf; qué es y para qué sirve

En el día de hoy os vengo a hablar de un fichero bastante poco conocido por el usuario "medio"; un fichero que, aunque no es un fichero indispensable, realiza tareas bastante relevantes que podemos querer analizar y/o modificar. Dicho fichero se llama nsswitch.conf, un fichero almacenado en /etc que generalmente pasa desapercibido pero que puede sernos útil, ya sea para conocer su función o para modificarlo a nuestro antojo. Dicho fichero, llamado también Name Service Switch configuration file, tiene como objetivo especificar de donde obtienen la información ciertos valores especiales, también llamados categorías, relacionados con GNU C Library, y en caso de obtener la información de varios orígenes, en qué orden consultar éstos con el fin de saber qué fuente tiene más prioridad. Estas categorías son referenciadas con un nombre único que ya está previamente establecido en el sistema, con lo que no es necesario crear ningún tipo de categoría "extra".

nsswitch.conf

Esto puede parecer un poco lioso, pero el concepto es mucho más simple de lo que parece... Lo mejor para entender adecuadamente este fichero, y los conceptos relacionadas con éste, es observar el contenido de este; he aquí un fichero de ejemplo que puede servir como una buena referencia:

  1. passwd:         compat
  2. group:          compat
  3. shadow:         compat
  4. gshadow:        files
  5. hosts:          files mdns4_minimal [NOTFOUND=return] dns
  6. networks:       files
  7. protocols:      db files
  8. services:       db files
  9. ethers:         db files
  10. rpc:            db files
  11. netgroup:       nis

Probablemente os hayáis quedado igual que antes; pero en seguida veréis que el fichero está perfectamente estructurado, pues tiene la siguiente composición:

  • Columna 1: El nombre de la categoría a la que se quiere hacer referencia.
  • Columna 2 o más: Fuentes de donde obtener la información. El valor más a la izquierda sería el primer lugar donde "buscaría" la información, luego el siguiente y así sucesivamente.
  • Valores entre [ ]: Son parámetros opcionales que se pueden introducir; especifican qué hacer en caso de haber obtenido un resultado en concreto del anterior fichero; Por ejemplo en la 5 línea de este fichero vemos que en caso de haber encontrado mdns4_minimal, pero no haber encontrado lo que se buscaba, el fichero dejaría de buscar fuentes de donde obtener la información e informaría de la carencia del fichero en cuestión.

Obviamente lo más importante sería conocer qué categorías podemos manejar... El abanico de posibilidades es bastante amplio, pero los más usados serían los siguientes:


  • aliases: Esta categoría contiene los alias usados para el envío y recepción de mails dentro del sistema. 
  • ethers: Número de interfaces ethernet.
  • groups: Esta categoría hace referencia a los grupos de usuarios del sistema; grupos que generalmente podemos consultar mediante el comando con el mismo nombre consultando el fichero /etc/groups.
  • hosts: Esta categoría hace referencia a la resolución de nombres, el cual envuelve diferentes aspectos, tales como los hosts "estáticos" y la resolución de nombres vía DNS.
  • networks: Especifica el nombre de algunas redes junto con sus respectivas ips; por ejemplo, gracias a esto el sistema es capaz de reconocer que la ip 127.0.0.1 es "loopback".
  • passwd: Categoría que contiene la información relativa a las contraseñas de los usuarios almacenadas /etc/passwd.
  • protocols: Esta categoría contiene el nombre de un gran número de protocolos.
  • services: En mi opinión, una de las categorías más importantes; contiene la información de los servicios usados. Información que relacionada con el nombre de cada servicio y el puerto de red que usa cada uno.
  • shadow: Contiene toda la información relativa a las contraseñas del usuario almacenadas en /etc/shadow.

Si bien ya conocemos las categorías, faltaría conocer a qué fuentes podemos apuntar. Tenemos la posibilidad de apuntar a ciertas fuentes concretas como puede ser mdns4_minimal... pero lo más común es hacer referencia a una librería o a un fichero en concreto... El mencionar estas librerías o ficheros manualmente diciendo exactamente a qué referencias puede ser una locura, con lo que existen métodos abreviados que pueden facilitarnos la vida. En concreto 4:

  • db: Esto busca en /lib/libnss_db.so toda la información relacionada con la categoría que buscamos. El problema está que la información almacenada allí no se puede leer con facilidad. Además la librería en cuestión no está instalada por defecto, no lo que si queremos usarla necesitariamos instalarla mediante:
apt-get install libnss-db
  • nis: Esto busca en /lib/libnss_nis.so toda la información relacionada con la categoría que buscamos; tiene las mismas desventajas que db, así que si queremos usar esa librería tenemos que hacer:
apt-get install libnss-nis
  • files: La referencia más útil de todas ya que esta está relacionada con ficheros claramente legibles y modificables. Cada vez que pongamos que la fuente de una categoría es files; nsswitch buscará en /etc un fichero con el mismo nombre que la categoría; en caso exitoso leería la información almacenada en este, información que podemos haber modificado con anterioridad a nuestro antojo.
  • compat: Es exactamente lo mismo que files, con la diferencia de en caso de poner compat, estaríamos otorgando al usuario que esté ejecutando nsswitch los permisos suficientes para acceder al sistema; es por ello que es necesario usar compat en vez files para passwd, groups y shadow. Esta referencia también es denominada "Compatibility Mode".

Por último estarían los parámetros opcionales, que ayudarían a "hilar más fino" en las consultas de las diferentes fuentes. Estos en sí no suponen una gran diferencia a la hora de realizar las consultas pero podemos hacer que se realicen determinadas acciones en caso de cumplirse o incumplirse ciertas condiciones o eventos. Los eventos serían nada menos que 4:

  • SUCCESS: Este evento significaría que la consulta de la anterior fuente ha sido exitosa; es decir que no sólo ha realizado la búsqueda, sino que además se ha encontrado lo que se buscaba. 
  • NOTFOUND: El texto en cuestión no es tan informativo que uno pensaría a primera vista. Este evento significaría que se ha encontrado la fuente especificada (ya sea un fichero lo que uno desee) pero que no se ha encontrado la información que se buscaba dentro de dicha fuente.
  • UNAVAIL: Esto significaría que la fuente en cuestión, ya sea un fichero o una librería, no existe o no es legible. 
  • TRYAGAIN: Esta es la situación es la menos común de todas. Esto significaría que el fichero estaría disponible pero que no podría ser leído debido a que está siendo ya leido por otro recurso o porque no se tienen los permisos adecuados.

Con estos 4 eventos podemos hacer dos cosas; la primera sería detener la ejecución y la segunda sería decirle a nsswitch que continue (cosa que generalmente hace por defecto). Esto se haría especificando return para detenerse y continue para continuar adelante, independientemente del resultado.Además podemos poner el simbolo ! antes del evento para decir que queremos que esa condición o evento en concreto no se cumpla. He aquí dos ejemplos prácticos:

[SUCCESS= return] --> En caso de haber ocurrido el evento SUCCESS, nsswitch se detendrá y devolverá el resultado.

[!SUCCESS = continue] --> En caso de NO haber ocurrido el evento SUCCESS, nsswitch continuará leyendo el resto de fuentes disponibles (en caso de haberlas).

Con estos conceptos ya seríamos capaces de entender e incluso modificar el comportamiento de nsswiwtch, pudiendo especificar y alterar las fuentes de donde se obtienen ciertos nombres, y el orden de lectura de dichas fuentes.

Espero que con esto os haya quedado un poco más claro el abstracto mundo de nsswitch.

Saludos.

viernes, 8 de abril de 2016

Cómo cambiar la duración de las conexiones inactivas en Linux

Las redes no siempre son sencillas de configurar y mantener; en éstas pueden fluir miles de millones de datos que no siempre podemos controlar; ya sea porque las aplicaciones que generan dicho tráfico no se pueden modificar o debido a que que la red no ha sido configurada por nosotros... Es por eso que a veces tenemos la mala suerte de encontrarnos con configuraciones inadecuadas de red o tráfico de paquetes de red no deseados que, de un modo u otro, hacen que las conexiones hacia nuestro servidor, no sean tan óptimas como nos gustaría. Una de las peores cosas que nos pueden ocurrir es que una conexión se quede establecida entre un equipo y nuestro servidor, pero que no fluyan datos por ésta, manteniendo un puerto de escucha ocupado en nuestro servidor (con su respectivo consumo de memoria) y pudiendo llegar a saturar éste en caso de tener muchas conexiones de este tipo. En ocasiones como estas, uno de los factores más determinantes que pueden ayudarnos a evitar conflictos como éstos. Es el concepto keepalive.

Portada_conexiones_inactivas

Keepalive se encarga de comprobar si una conexión se mantiene activa o no. Para ello lo que hace es calcular el tiempo que transcurre desde el último paquete de datos recibido, con lo que si pasan una serie de segundos (previamente establecidos), el servidor intentará reconectar con el otro equipo un número determinado de veces cada X segundos... La cuestión está en que aunque la desconexión es realizada por el servidor, este tarda mucho en realizarla por "culpa" de los valores por defecto que tiene establecidos; valores que en entornos ideales no dan problemas, pero que en otros en cambio son más perjudiciales que beneficiosos.

Los valores que se encargan de establecer el "tiempo de vida" son tcp_keepalive_time, tcp_keepalive_intvl, tcp_keepalive_probes. La combinación de esos tres valores son las que consiguen que tengamos un tiempo de desconexión determinado, pero es importante saber diferencias las funciones de cada uno de éstos, pues son completamente diferentes los unos de los otros:

  • tcp_keepalive_time: Establece el tiempo necesario que tiene que pasar sin recibir paquetes desde el otro equipo para empezar a mandar paquetes "keep alive"; paquete que en caso de que el otro lado estuviese activo/online recibiría respuesta. El valor por defecto son 7200 segundos (2 horas).
  • tcp_keepalive_intvl: El intervalo de tiempo entre cada envío de paquetes "keep alive"(independientemente de que la conexión esté " viva o muerta"). El valor por defecto son 75 segundos.
  • tcp_keepalive_probes: Establece el número de paquetes "keep alive" sin respuesta necesarios para considerar que una conexión está "muerta".  El valor por defecto son 9 intentos.

Teniendo en cuenta todos estos valores veríamos que el total de tiempo que tendría que transcurrir para considerar una conexión completamente muerta sería de: 2 horas + (75 segundos * 9 intentos /60 segundos) = 2 horas, 11 minutos y 25 segundos... En definitiva; mucho tiempo; demasiado en algunos casos.

Para modificar estos valores podemos hacerlo o bien directamente para la sesión actual (que al reiniciar el equipo volverían a tener sus valores originales) o a nivel de kernel en sysctl para hacer los cambios persistentes... Esto es debido a que estos valores están almacenados en ficheros separados con el mismo nombre dentro del directorio virtual /proc/sys/net/ipv4/, así que estaríamos hablando de valores que afectarían directamente al núcleo del sistema. Es importante saber que, si bien se está efectuando un cambio sobre parámetros ipv4; estos parámetros en concreto también afectan a ipv6, con lo que no estaríamos dejando ningún cabo suelto. Si deseásemos hacer que el tiempo sin recibir paquetes fuese de 10 minutos (600 segundos) y que tras dicho intervalo de tiempo hiciese un máximo de 10 intentos fallidos cada 60 segundos, tendríamos dos formas de hacerlo.

La primera y más rudimentaria sería modificando los ficheros correspondientes a mano para que únicamente fuesen válidos hasta el próximo reinicio; esto se haría mediante estos tres comandos:

  1. echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
  2. echo 60 > /proc/sys/net/ipv4/tcp_keepalive_intvl
  3. echo 10 > /proc/sys/net/ipv4/tcp_keepalive_probes

La solución es perfectamente válida, pero la verdad es que es algo chapucera, ya que rara vez se aplican estos cambios de forma temporal; y menos cuando dicha temporalidad depende de evitar reiniciar el equipo... Es por ello que es mucho más eficiente aplicar los cambios de forma permanente introduciendo los parámetros en /etc/sysctl.conf.

  1. echo 'net.ipv4.tcp_keepalive_time = 600' >> /etc/sysctl.conf
  2. echo 'net.ipv4.tcp_keepalive_intvl = 60' >> /etc/sysctl.conf
  3. echo 'net.ipv4.tcp_keepalive_probes = 10' >> /etc/sysctl.conf
  4. sysctl -p

Con esto sí que tendríamos los cambios aplicados de forma permanente, haciendo que nuestras conexiones estuviesen mucho menos tiempo "muertas". Si quisiésemos añadir más flexibilidad a estas reglas o ser más restrictivos con estas conexiones, solamente habría que jugar con estos parámetros hasta conseguir el balance ideal.

Espero que os haya resultado útil.

Saludos.

martes, 5 de abril de 2016

Alien, el conversor universal en Linux

Hola a todos; hoy os vengo con un pequeño  pero muy interesante articulo que a más de uno le puede resultar muy útil. Todos sabemos que Linux está lleno de diferentes "sabores"... A algunos les gustan más los sistemas relacionados con el mundo empresarial como pueden ser CentOS o Red Hat, mientras que otros prefieren optar por el clásico Ubuntu por la gran cantidad de información disponible en Internet, o Debian por su estabilidad. Otros prefieren optar por sistemas menos conocidos y escogen sistemas como Arch o Manjaro... Todos pertenecen a Linux, pero cada sistema operativo tiene sus particularidades y sus características que lo convierte en un "sabor" único. Aún así la gran mayoría se pueden englobar en tres grandes categorías (hay más, pero serían las más conocidas): Debian, Red Hat y Arch. Esto es debido a que si bien existe una enorme variedad de sistemas disponibles, la gran mayoría están basados en sistemas ya existentes, sistemas que en la gran mayoría de las veces son los tres que he mencionado; especialmente los dos primeros, ya que Arch es bastante menos conocido/usado.

Debian y Red Hat tienen muchas diferencias entres sí, y si bien con la llegada de systemd se han puesto varias cosas en común; todavía existen muchas características únicas de estos dos sistemas. Entre ellas estarían los paquetes que éstos usan: RPM para Red Hat y DEB para Debian.

A la hora de querer instalar un nuevo software en una distribución, tendríamos dos opciones disponibles: La primera y más práctica sería recurrir al gestor de paquetes del sistema operativo, con el cual podemos instalar casi instantáneamente una enorme cantidad de herramientas; dichos gestores se denominarían apt-get en Debian y yum en Red-Hat. Obviamente estos repositorios no son infalibles y no tienen todos los paquetes existentes, con lo que a veces es necesario instalar los paquetes .deb o .rpm a mano, cosa bastante sencilla en general; ¿Pero qué pasa cuando dichos paquetes no existen? ¿Qué pasa cuando buscamos un paquete para Debian pero solo existe para Red Hat o viceversa? Ahí es donde entraría la herramienta de la que os quiero hablar hoy: Alien.

alien_portada

Alien es una herramienta muy sencilla e intuitiva que permite convertir paquetes de formato deb en rpm y viceversa. La conversión generalmente da problemas y convierte casi al instante los paquetes de un formato a otro, ahorrándonos tener que recurrir a métodos o herramientas alternativas. La conversión de un paquete .deb a .rpm se realizaría usando esta estructura:

alien -d paquete.rpm

En cambio si deseásemos realizar una conversión inversa; es decir de .rpm a .deb, usaríamos el parámetro -r:

alien -r paquete.deb

Un buen ejemplo de ello sería el paquete Networker; también conocido como lgtoclnt.

alien -d lgtoclnt-7.5.1-1.i686.rpm

El problema que tiene dicha conversión es que por defecto no incluye los scripts de pre-instalación y post-instalación; scripts que aplicarían las configuraciones relacionadas con el paquete. Esto en la mayoría de las ocasiones puede ser un problema, con lo que lo mejor es incluirlos mediante el parámetro --scripts.

alien --scripts -d lgtoclnt-7.5.1-1.i686.rpm

Además, alien es capaz de tratar con más paquetes además de los rpm y lo deb, que si bien son menos conocidos, existen. En concreto es capaz de tratar los paquetes tipo .tgz (pertenecientes a Slackware), los paquetes .slp (pertenecientes Stampede) y paquetes LSB. La conversión a dichos formatos se realizaría mediante los siguientes parámetros:
  • -t: Conversión a formato .tgz.
  • --to-slp: Conversión a paquetes .slp.
  • -l: Conversión a formato LSB.

Como podéis ver las características de este conversor nos puede permitir transformar paquetes que en un principio no estaban disponibles para nuestras distribuciones, convirtiéndola en una herramienta de un valor incalculable.

Espero que os haya resultado útil.

Saludos.