por ·2 comentarios

Screenshot de Hydrigen en acción - Click para ampliar

Screenshot de Hydrigen en acción - Click para ampliar

Leyendo algún blog –que ahora no puedo recordar como para darle todos los créditos– me encontré con un enlace a este espectacular tutorial / Manual sobre herramientas de producción musical en Linux.

Consta en total de 5 capítulos y explica –no tan en produndidad como yo quisiera pero lo suficiente como para darse un pantallazo general-, el uso de unos cuantos programas para grabar, secuenciar, samplear, mezclar y remasterizar en linux.

Si bien se trata de varias programas separados, todos interactúan entre si de forma transparente como si fueran uno solo por medio del protocolo Jack, con lo que el resultado final nada tiene que envidiarle a Reason o Cubase para windows.

Se da un vistazo General a Audacity y Rezound para grabar y generar tracks y samples para pasarle a la caja de ritmos, Hydrogen como caja de ritmos (un joyita de programa, para sacarse el sombrero), Ardour / Rosegarden como secuenciadores y Jamin para el masterizado final…

El curso en cuestión:

En Gentoo todo lo que tuve que hacer para instalar toda la suite de aplicaciones fué agregar a mis use flags: lv2 mad lame jack ladspa.

Todas las aplicaciones están disponibles en el overlay pro-audio y funcionan a la primera.

Hasta el momento la única complicación que he encontrado: El servicio jack solo corre como root y no funciona como usuario normal sin privilegios. Para solucionarlo tuve que agregar al archivo /etc/security/limits.conf :

* – rtprio 99
* – nice -10
* – memlock 4000000

por ·Sin comentarios

No son leyenda urbana. Los kernel panics existen…

Mientras el hardware esté sano, linux no falla, pero ¿Y si el hardware falla? ¿Y si falla en un servidor al cual no tenemos acceso físico? En esos casos es vital que la pc o el servidor remoto reinicien automáticamente después de un kernel panic.

El kernel de linux por defecto no reinicia el sistema en caso de un kernel panic de forma de que sea accesible por pantalla el volcado de memoria y el error específico, y esto no siempre es lo que se necesita (sobre todo si el sistema remoto no tiene un monitor instalado o no hay nadie presente físicamente en el lugar).

Para lograr que el kernel reinicie el sistema en caso de un kernel panic hay que modificar el contenido del archivo /proc/sys/kernel/panic:

~ # echo 5 >> /proc/sys/kernel/panic

Donde 5 es la cantidad de segundos que queremos esperar antes de que se produzca el reinicio del sistema.

Verificando el contenido del archivo:

~ # cat /proc/sys/kernel/panic
5

De esta forma el cambio de aplica de manera inmediata, pero como el contenido del archivo panic es volatil, los cambios se pierden luego del primer reinicio del sistema operativo.

Para que el cambio sea efectivo de forma permanente hay que implementarlo sobre el archivo /etc/sysctl.conf descomentariando la siguiente línea:

# When the kernel panics, automatically reboot in 3 seconds
#kernel.panic = 3

O bien, pasarle el parametro en cuestión al kernel durante el arranque desde el boot loader, por ejemplo, agregando panic=5 a /boot/grub/menu.lst:

kernel /boot/kernel root /dev/sda1 panic=5

Usando la combinación de el parámetro panic con la opción fallback de grub  es posible por ejemplo, testear un nuevo kernel de manera remota, de esta forma, en caso de un kernel panic arrancando un nuevo kernel grub puede arrancar al segundo intento desde un kernel viejo, sistema de archivos viejo, etc, etc, pero eso es tema para otro artículo.

por ·7 comentarios

Viene de este otro artículo anterior, a raíz de la necesidad de ejecutar aplicaciones remotas en el servidor X local usando X11-Forwarding sin que se nos pregunte una contraseña. (Ideal para el acceso directo de la dama o el alias de bash del caballero).

Normalmente, si necesitamos conectarnos a un servidor SSH habitualmente, tendríamos que especificar el nombre de usuario y una contraseña. (Se especifica el usuario únicamente si nos autenticaremos remotamente como un usuario distinto al usuario que localmente ejecutará ssh)

Al cabo de un tiempo esto termina volviéndose tedioso por lo que usar un juego de llaves (key authentication) es la mejor solución.

Por otro lado, desde el punto de vista de la seguridad, –además de correr sshd en un puerto no privilegiado (de 1024 en adelante) y el buen fail2ban controlando los logs- la autenticación por llaves es muchísimo mas confiable en la medida en que nuestra clave privada se mantenga así (privada) y no caiga en manos de nadie.

Habiendo generado nuestro par de llaves RSA para autenticación ssh, una llave privada, y una pública, basta con copiar nuestra llave pública a todo servidor o pc contra la cual nos autenticaremos para que nos deje entrar sin preguntar quien está en la otra punta ni cual es la contraseña.

Sea cual sea el motivo que te lleve a implementar autenticación por llaves, por comodidad o por seguridad, veamos como se pone en funcionamiento:

Generar el par de llaves:

El comando ssh-keygen, que viene de serie con el paquete openssh es el encargado de generar nuestro juego de llaves:

~ $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mn/.ssh/id_rsa):
Created directory ‘/home/mn/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mn/.ssh/id_rsa.
Your public key has been saved in /home/mn/.ssh/id_rsa.pub.

Dejando la contraseña (passphrase) en blanco durante el proceso, he generado mis dos llaves, la pública: id_rsa.pub dentro del directorio /home/mn/.ssh/  y la privada: id_rsa dentro del mismo directorio.

Copiar la llave pública a la ubicación remota:

Usando secure copy movemos nuestra clave pública hasta el servidor que frecuentamos:

~ $ scp ~/.ssh/id_rsa.pub usuario@servidor:

Instalar la llave pública en la ubicación remota:

Nos logueamos en el servidor (que todavía nos preguntará la contraseña):

~ $ ssh usuario@servidor

Password: **********
Last login: Wed Jul 29 23:19:44 ART 2009 from 5.192.233.114 on ssh

Y copiamos el contenido de nuestra llave pública dentro del archivo authorized_keys en el directorio  ~/.ssh/:

~ $ cat id_rsa.pub >> ~/.ssh/authorized_keys

~ $ exit

¡Y eso es todo!

Si nuevamente intento loguearme usando SSH en este servidor, ya no pregunta mi contraseña. Mi llave privada se coteja contra la llave pública y me permite el acceso de forma cómoda e instantanea:

~ $ ssh usuario@servidor
Last login: Wed Jul 29 23:20:09 ART 2009 from 5.192.233.114 on pts/0
servidor ~ $

Es importantísimo tener en cuenta que este método planteado, si bien es mucho mas seguro que el método tradicional de autenticación –que es vulnerable a ataques de fuerza bruta– a la vez representa un gran riesgo para la seguridad si alguien se hace con nuestra llave privada.

Quien tenga acceso local a la pc que almacena la llave privada automáticamente tiene acceso remoto a las pc o servidores que conocen nuestra llave pública.

Existiendo la posibilidad de especificar un password en nuestra llave privada automáticamente el sistema se vuelve seguro ya que en el caso de que este password no esté en blanco:

  • El acceso SSH no es vulnerable a ataques de fuerza bruta.
  • Nuestra clave privada no se puede desencriptar sin conocer el password.
  • Se nos pide el password de la clave privada en lugar de el password de usuario para iniciar sesión.

En este último caso se pierde la comodidad de loguearnos sin contraseña. Se nos pregunta la contraseña pero de la llave y no del usuario en cuestión. Esto también se puede automatizar haciendo uso de ssh-agent, pero es tema para otro artículo, para no complicar demasiado las cosas.