Soy un tanto fanático de los sistemas operativos. Y si algo me ha llamado la atención desde que uso Linux y algún que otro Unix, son los sistemas operativos que no son descendientes de Unix. Parecieran haber mil variantes de Unix: Linux, los BSD, Solaris, Irix, MacOSX, HP-UX, etc. Pero sistemas operativos no Unix aparte de nuestro bien (o mal) conocido Windows parecieran no existir. Sin embargo no es así y una investigación del tema nos deja ver que han habido muchos intentos de reescribir la historia de los sistemas operativos no Unix. Les dejo acá una lista con algunos de ellos aunque no están todos. He dejado a Windows al final para no aburrirlos, aunque su historia es bastante interesante. Aquí la lista, por si no conocían a alguno:

BeOS

BeOS Fue desarrollado en la década del 90, por una empresa francesa, y era un SO orientado al escritorio. Por ello, el sistema era monousuario y estaba optimizado para trabajar con audio video y 3D. La interfáz gráfica estaba construida en el mismo sistema operativo, y era muy sencilla, limpia y amigable. El kernel de BeOS (un micokernel) hacía un uso intensivo del los multithreads (multihilos), mucho más que otros sistemas operativos. BeOS tenía la particularidad de bootear en unos segundos.

Lamentablemente BeOS fue una más de las víctimas de Microsoft. Cuando la empresa que comercializaba este sistema operativo quiso distribuirlo preinstalado en ordenadores nuevos, recibió una amplia negativa de los vendedores de pc’s ya que que la mayoría de estas empresas tenían un acuerdo con Microsoft para distribuir solamente Windows con los equipos nuevos. Aunque BeOS ganó el juicio contra Microsoft por prácticas monopólicas, la empresa cayó en bancarrota y en 2001 la propiedad intelectual de BeOS fue vendida a Palm que nunca demostró darle algún uso.

Luego de que BeOS cayera en desgracia muchos de sus seguidores trataron de resucitar el sistema. Alguna empresas siguieron desarrollandolo tomando como base la última release del sistema operativo, luego de obtener una licencia de Palm. Otras como OpenBeOS, luego llamado Haiku, se propusieron reescribir todo el código de BeOS bajo una licencia open source.

AmigaOS y AROS

AmigaOS no es un sistema operativo para la plataforma x86, pero se hizo muy popular por ser el sistema operativo de las consolas Amiga, desarrolladas por Commodore en los años 80 y 90. Aunque estas microcomputadoras estaban pensadas como consolas de juego, luego se agregaron funciones a su sistema operativo que permitieron que el usuario utilizara la consola con un completo sistema gráfico de escritorio.

El sistema operativo de las primeras consolas residía en parte en una memoria ROM, desde la cual se podía iniciar el sistema y luego cargar juegos desde un diskete. Aún así era posible cargar un disco en el que se terminaban de cargar todas las funciones del sistema operativo y una interfaz de escritorio que en los sistemas Amiga se llama Workbench.

Una de las particularidades que destaca a AmigaOS es su excelente soporte para multiarea. El núcleo de AmigaOS es del tipo microkernel y todo el sistema operativo ocupa menos de 1 Megabyte, por lo cual se puede decir que es un sistema excelentemente optimizado ya que pese a su tamaño no deja de ser potente.

Aunque las consolas amigas ya no se producen más, el desarrollo del sistema operativo ha seguido adelante. La última versión de AmigaOS, la 4.0, se produce hoy para computadores con procesaores ppc de IBM (a diferencia de los procesadores motorola de las consolas originales), e incluye un completo escritorio (o Workbench) con muchas capacidades.

Un sistema operativo de investigación, llamado AROS, ha sido desarrollado como un clon de AmigaOS. Aunque AROS no tiene compatibilidad a nivel binaria con las aplicaciones de AmigaOS, sí soporta la api de dicho sistema operativo y a nivel de código fuente los programas de AmigaOS son bastante compatibles con AROS. Las versiones actuales de AROS están disponibles para la plataforma x86 y para ppc. Algo que destaca de AROS es que su desarrollo es open source.

Plan 9

Plan9 es un sistema operativo desarrolado por Bell Labs de AT&T (hoy Alcatel-Lucent), los mismos desarrolladores de Unix y de los lenguajes de programación C y C++. Plan9 fue ideado como el sucesor de Unix, e incluye conceptos bastante innovadores, pero aún así no ha conseguido sobrepasar en popularidad a su antecesor.

Plan9 es un sistema operativo distribuido y se divide en tres componentes principales: los terminales desde donde trabajan los usuarios, los servidores de archivo que almacenan los datos y los servidores que realizan el procesamiento de los datos y las tareas de autenticación y funciones de red. Plan9 presenta varias ideas innovadoras, por ejemplo, todos los objetos del sistema operativo son considerados y tratados como archivos que pueden existir de forma remota o local. Esta última característica hace que el acceso a la red en Plan9 sea totalmente transparente. Por ejemplo si se abre una conexión a un servidor FTP, los archivos remotos se presentan al sistema operativo como si fueran locales.

Es interesante que el concepto del directorio /proc, que representa los procesos y la información manejada por el kernel como archivos, fue desarrollado para Plan9, aunque luego se incorporó la idea en sistemas Unix como Linux. Así mismo el sistema de archivos Union, que permite ver dos sistemas de archivos como si fueran uno, también fue ideado por los desarrolladores de este sistema operativo. Otra notable contribución de los desarrolladores de Plan9 es la codificación UTF-8, que hoy se ha hecho tan popular.

Aunque las primeras releases de Plan9 no eran libres, a partir de su cuarta versión se liberó bajo una licencia open source. Desde la página del proyecto es posible descargar un live cd desde el que también es posible instalar el sistema operativo.

MenuetOS

MenuetOS es un sistema operativo para 32 y 64 bits para la arquitectura x86 escrito enteramente en lenguaje ensamblador. El sistema en sí es bastante sencillo y ha sido desarrollado tratando de eliminar los elementos que hacen que la programación de un SO sea complicada y proclive a contener bugs.

El sistema entero cabe en un diskette, aun así, posee una interfaz gráfica que soporta una resloución de 1280×1024 y 16 millones de colores. MenuetOS tiene una completa pila TCP/IP y viene además con un IDE para ensamblador y clientes para e-mail, ftp y http. La versión para 32 bits puede obtenerse bajo una licencia open source, a diferencia de la versión de 64 bits que tiene licencia propietaria.

SkyOS

SkyOS es un sistema operativo orientado al desktop para la platarforma x86. Soporta procesamiento simétrico, multitrheading y es multitarea. La interfaz de usuario es sencilla y elegante y está directamente construida sobre el kernel, de manera que el sistema operativo es totalmente gráfico. Varias aplicaciones libres como Mozilla Firefox y otras han sido portadas a este sistema operativo.

Este sistema operativo es propietario, y está en fase beta; a la fecha, su desarrollo no parece muy activo. Es posible descargarlo y probarlo como beta tester luego de pagar una licencia.

GNU/Hurd

Hurd es el kernel desarrollado por la Free Software Fundation con el fin de reemplazar el kernel Unix. Hurd implementa varios servicios alrededor de un microkernel (Actualmente Mach) que realizan de forma separada todos los procesos que haría un kernel monolítico como el de Unix. Cada uno de estos servicios proveen entre otras cosas acceso al filesystem, manejo de la red, control de procesos, etc.

Aunque se esperaba que Hurd supliera el kernel para correr las aplicaciones GNU, esto no sucedió. El desarrollo de Hurd ha tomado mucho tiempo y todavía no está completo ni es recomendable para su uso en producción. Quizás el desinterés en Hurd se deba a que el kernel de Linux llegó a ser un muy buen reemplazo del kernel de Unix para el entorno GNU.

Algunas distribuciones de Linux como Debian y Gentoo proveen algo de soporte para el kernel Hurd, pero este soporte como el sistema operativo mismo, es bastante experimental. Debian ofrece incluso algunos cd’s instalables con un sistema GNU/Hurd.

AtheOS y Syllable

AtheOS es un sistema operativo iniciado por un programador noruego, Kurt Skauen. AtheOS fue escrito desde cero como un clon del sistema operativo AmigaOS aunque luego este objetivo fue descartado en favor de hacer de AtheOS un sistema operativo compatible con la arquitectura x86. Este sistema operativo soporta multithreading (hace uso muy intensivo de él) y procesamiento simétrico (smp, o multiples procesadores).

AtheOS está orientado al escritorio, funciona solo en modo gráfico, y cuenta con algunas aplicaciones gráficas como un emulador de terminal, un gestor de archivos y un navegador basado en el motor de KHTML (el mismo de Konqueror) llamado ABrowse; así como un cliente de correo electrónico. La interfaz gráfica está construida dentro del mismo sistema operativo y está escrita en C++ lo que la hace totalmente orientada a objetos. A su vez, esta interfaz es nativa y no utiliza el sistema X11, aunque mantiene un esquema de funcionamiento del tipo cliente-servidor como X11 pero sobre un protocolo de comunicación más agil que no es tcp/ip. El sistema maneja su propio tipo de filesystem AFS (AtheOS Filesystem), que no debe confundirse con el Andrew Filesystem. AtheOS fue liberado bajo la GPL y varias personas han contribuido a su desarrollo, también se han portado varias aplicaciones libres a este sitema operativo como Apache, Bind y varias librerías importantes.

Luego de un tiempo, el desarrollador de AtheOS abandonó el proyecto y descontinuó el desarrollo. Sin embargo los seguidores de este sistema operativo tomaron la posta y crearon un fork del mismo originando el sistema Syllabe, basdo en AtheOS. Según sus desarrolladores, su meta es crear un sistema operativo open source, estable, fácil de usar, intuitivo y potente para usuarios finales y de oficina. Además afirman que Syllable es muy liviano y bootea en apenas unos segundos. De hecho algunos usuarios afirman que es más el tiempo que tarda la BIOS en realizar el POST que el que tarda Syllable en bootear.

Aunque Syllable está aún en desarrollo, y le falta mucho trabajo para llegar a ser un sistema completo; su desarrollo es muy activo y muchas aplicaciones están siendo portadas a este sistema. Además se han desarrollado drivers para varios dispositivos de hardware de uso común como tarjetas de video, sonido y red.

Morphos

MorphOS es un sistema operativo desarrollado para ser compatible con el hardware de los sistemas Amiga basados en procesadores power pc de IBM. La empresa que lo patrocina, Genesi, fabrica los sistema Pegasos que son computadoras con procesadores ppc, así como las placas efika, que son pequeñas placas madres (muy similares a las famosas Via Epia) también con procesador ppc y que incluyen varios dispositivos como sonido, red, usb y audio integrados.

MorphOS está construido sobre el microkernel Quark y permite correr aplicaciones antiguas para los sistemas Amiga a través de un emulador. Además corre nativamente las aplicaciones más nuevas de AmigaOS a través de una implementación de la api de de este sistema operativo. Aunque MorphOS en sí es un sistema propietario, partes del sistema como el escritorio (llamdo Ambient), y varias bibliotecas de funciones han sido liberados bajo la licencia GPL.

La interfaz gráfica de MorphOS es muy limpia y amigable y es compatible con el Workbench de AmigaOS. Un navegador web basado en KHTML, llamado Sputnik está siendo desarrollado, además la pila TCP/IP del sistema, llamada MOSNET es también un proyecto open source. Otros programas bajo licencia libre han sido portados y varios programas freeware y shareware están disponibles para esta plataforma.

MorphOS está disponible solo para los propietarios de hardware de Amiga, o compatibles como Pegaos o Efika, que deben registrarse para poder bajar el sistema e instalarlo.

OS/2

OS/2 es un sistema operativo desarrollado en un principio por Microsoft e IBM. Luego de algunas desavenencias, el acuerdo entre Microsoft e IBM se rompió e IBM siguió el desarrollo de OS/2 por su cuenta, mientras que Microsoft se enfocó en su sistema Windows 3.0. OS/2 fue gestado como el sucesor de DOS, aunque nunca logró este objetivo, ya que Windows 3.0, 3.1 y 95 en adelante se convirtieron en los entornos gráficos de facto de la mayoría de las pc’s de escritorio. Aún así el desarrollo de OS/2 se mantuvo activo por varios años y llegó a ser un sistema operativo excelente, que para muchos usuarios siempre superó con creces a los sitemas Windows, ya que se destacó por su muy buena estabilidad.

OS/2 implementó la multitarea mucho antes que los sitemas Windows. Además en su versión 2.0 se agregó una potente interfaz gráfica y la posibilidad de ejecutar aplicaciones para DOS y Windows. OS/2 soporta tanto el sistema de ficheros FAT de DOS así como un sistema nativo, el HPFS (High Performance File System). La primera versión de OS/2 fue liberada en 1987, y de ahí en más se lanzaron nuevas versiones con más funcionalidades. Entre ellas, una de las que más se destacaba era el soporte para redes TCP/IP que IBM introdujo de forma temprana en su sistema operativo de escritorio. La última versión de OS/2 liberada fue la version Warp 4.0 que apareció para el año 1996, más o menos para el mismo tiempo que Windows 95. Esta fue la última versión de este sistema operativo, aunque luego se lanzaron packs de actualizaciones, pero no nuevas versiones.

IBM no ha mostrado ya más interés en OS/2 desde la version Warp 4.0. Para el años 2005 IBM dejó de vender OS/2 y el soporte oficial finalizó en diciembre de 2006. Aún así una empresa llamado Serenity Systems obtuvo una licencia de IBM para seguir desarrollando OS/2 y venderlo bajo el nombre de eComStation, sistema que sigue vendiendo hasta hoy día. Muchos usuarios y fanáticos este sistema operativo han pedido en reiteradas ocasiones a IBM que libere el código fuente de OS/2 ya que lo consideran una especie de abandonware. Recientemente IBM comunicó que no está interesado en liberar el código fuente de este sistema operativo.

ReactOS

ReactOS es un sistema operativo clon de Windows NT y recientemente de Windows XP. Es una implementación libre de la arquitectura de estos sistemas operativos cerrados de manera que ReactOS trata de ser compatible binariamente con los programas y drivers de Windows NT y XP. ReactOS está en estado Alpha y por lo tanto, no se recomienda para uso en producción. Sus desarrolladores recomiendan ReactOS como un sistema operativo de investigación para estudiar la arquitectura de los sistemas Windows pero enfocandose en una implementación libre.
Los desarrolladores de este sistema operativo trabajan conjuntamente con los desarrolladores de Wine, el software que emula programas de Windows en Linux y Mac.

El proyecto manteiene una base de datos de compatibilidad de software y drivers para Windows. Cualquier voluntario puede testear alguna aplicación o driver en particular y ver si se ejecuta bien en ReactOS y si no lo hace, remitir la información para que se trabaje al respecto en el sistema operativo de forma que se aumente la compatibilidad.

Aunque la meta de este sistema es ser completamente compatible con Windows, una vez que alcancen este objetivo su equipo de desarrollo quiere añadirle características que Windows no posee como compatiblidad completa con POSIX.

Netware

Netware es un sistema operativo de Red. Lo que hace diferente a Netware de otros sistemas operativos es que no está orientado al usuario final o el escritorio, sino que solo cumple funciones de servidor. Netware fue desarrollado por Novell a principios de los 80 y fue toda una innovación para su tiempo porque corría sobre los procesadores 8086 de Intel. Novell pensaba además hacer su sistema operativo para que funcionara en red, en contraposición a los grandes mainframes de aquel tiempo donde los terminales se conectaban por puertos seriales al servidor central pero no usaban la red o lan. Para lograr este fin Novell se aprovechó plenamente de la tecnología Ethernet que era bastante reciente para su época y desarrolló un protocolo de comunicación que funcionaba sobre Etherntet, el IPX/SPX, que con el tiempo fue suplantado por TCP/IP.

Entre los servicios que brinda Netware a los terminales de la red local estan principalmente los de servidor de ficheros, impresión, directorio y autenticación. Varios productos de Novell como servidores de correo y groupware corren sobre Netware.

A finales de los 90, la popularidad de Netware fue decayendo Microsoft y sus productos como Windows NT y Windows 2000 que competía directamente con los servicios de directorio de Netware al introducir Active Directory. Con el tiempo las ventas de Netware decayeron pero aún así son muchas las empresa que todavía utilizan este sistema operativo que se destaca por ser eficiente y confiable.
Aunque Novell ha descontinuado el desarrollo de Netware, y se ha centrado en soluciones Linux, planea dar soporte a este sistema hasta el año 2015.

MacOS

MacOS/X es el sistema operativo que utilizan las computadoras de la empresa Apple, llamadas en un principo Macintosh, de ahí el prefijo “MAC”. Aunque actualemente todo el mundo conoce MacOSX, nos referimos aquí a MacOS (sin la X), ya que este último está basado en un kernel Unix y estamos hablando de sistemas operativos no Unix.

MacOS fue diseñado en un principo como un sistema operativo diferente; en contraste con Unix y DOS, MacOS era un sistema totalmente gráfico y carecía de línea de comandos. La intención de Apple era hacer que cualquier usuario pudiera usar una computadora y no tuviera necesariamente que aprender una gran cantidad de comandos técnicos. Los desarrolladores de este sistema se inspiraron en un desarrollo de la empresa Xerox que había creado la primera computadora personal con una interfaz gráfica que se manejaba con un ratón. Aún así Apple innovó con su sistema operativo en el campo de las interfaces gráficas al crear conceptos como el de arrastar y soltar y otros más que todavía se siguen usando en la computación gráfica y que otros sistemas operativos han imitado con el tiempo.

Los primeros sitemas MacOS corrían una parte en ROM y la demás se cargaba desde un diskete, ya que las primear macintosh carecían de disco rígido. Las primeras versiones de MacOS corrían en los procesadores 68000 de Motorola, pero luego se adaptó para correr sobre la plataforma ppc de IBM cuando Apple cambió a esta arquitectura.

Apple desarrolló también un protocolo de comunicaciones en red para MacOS, el AppleTalk, así como un sistema de ficheros particular, el HFS, que es bastante diferente de los utilizados en Windows o Unix.

Luego de la versión 9 de MacOS el sistema fue reescrito para correr sobre un kernel Unix tipo BSD, alrededor del cual está construida toda la interfaz gráfica que sigue teniendo las características principales de MacOS.

CP/M, QDOS, MS-DOS, Windows y un largo etc.

Windows parece no merecer introducción, es el rey de los sistemas operativos no Unix. Aún así la historia de Windows que está ligada a la de Microsoft es muy interesante. Los orígenes de lo que hoy se ha transformado en Windows se remontan a 1974 cuando Gary Kildall programó un sistema operativo llamado CPM/DOS que con el tiempo se hizo muy popular entre las computadoras personales de la época. Resultó ser que IBM estaba buscando un sistema operativo para vender con sus primeras computadoras personales y desde luego CPM/DOS parecía la mejor opción. Sin embargo las negociaciones entre IBM y Digital Research, la empresa de Gary Kildall, fracasaron e IBM decidió buscar otra opción. Esa otra opción fue precisamente Microsoft y quien estaba detrás de él, Bill Gates. Microsoft hizo un acuerdo para proporcionar el sistema operativo que acompañaría a las pc’s de IBM, aunque Microsoft ni siquiera tenía el sistema operativo que estaba vendiendo a IBM. Pero si se trata de negocios para Gates y Microsoft nada es imposible; de manera que Microsoft salío a comprar un clon de CMP/DOS llamado QDOS (Quick and Dirty Operating System, literalmente “Sistema Operativo Rápido y Sucio”) y lo rebautizó como MS-DOS. Desde luego el QDOS o MS-DOS era muy inferior a CPM/DOS, pero esto no impidió que las ventas de las computadoras de IBM dispararan la fama de Microsoft y MS-DOS de manera que CPM/DOS cayó en el olvido y nació él imperio de software y sistemas operativos más grande de la historia.

Para 1985 Microsoft decidió lanzar la versión 1.0 de su sistema Windows, que en realidad no era un sistema operativo, sino un sistema gráfico o GUI. Windows trataba de imitar el sistema gráfico de Apple, sin embargo tanto esta primera versión como la 2.0 no representaban ninguna ventaja para el usuario y no tuvieron éxito. Ahora bien la versión que sí marcó el éxito de Microsoft en el terreno de las intefaces gráficas. fue Windows 3, y 3.1, su sucesor. Estas versiones seguían siendo aplicaciones que corrían sobre DOS y no un sistema operativo real aunque trataban de emularlo. El primer intento de Microsoft de desligarse de DOS para traer un SO totalmente gráfico fue Windows 95, que sin embargo seguía dependiendo mucho de DOS y más bien parecía un híbrido entre una interfaz gráfica como Windows 3.1 y DOS. Windows 98 se alejó un poco más de MS DOS pero finalmente Windows Millenium fue el primer Windows que prescindia de MS DOS, sin embargo como es sabido Windows Me fue un tremendo fracaso. Tanto es así que Microsoft tuvo que apresurarse a sacar Windows XP, basado en su producto Windows NT para servidores. De ahí en más el desarrollo de XP y su actual sucesor Vista, es bastante conocido.

Lo que muchos no saben son las idas y vueltas que Microsoft ha hecho para posicionar sus sistemas operativos. Por ejemplo más de una vez Microsoft compró un producto de software o una empresa para cambiarle el nombre a algo “MS” y venderlo con su sistema operativo. Incluso uno de los desarrolladores principales de Windows NT estuvo trabajando mucho tiempo para DEC, tanto es así que cuando Microsoft lo contrató DEC entabló una demanda alegando que Microsoft se estaba llevando con sus ex empleado información importante de su sistema operativo OpenVMS para incluirlo en el código de NT.

Bien, esa es la lista con la reseña de los SO que he podido investigar hasta la fecha. Alguna información puede estar ligeramente desactualizada, (este mega-post llevaba archivado bastante tiempo). Sin embargo la lista nos muestra que el mundo de los SO es muy diverso y que pueden haber distintos enfoques para su desarrollo. Lo que también vemos es que el área de los SO es muy sensible tanto así que unos pocos sistemas operativos dominan el mercado. Sin embargo todo esto no deja de hacer que el tema sea fasciannte.

Lo primero que debemos instalar es un programita encargado de colorear los logs, se llama ccze

# aptitude install ccze

luego nos editamos el .bashrc en nuestro home y creamos la siguiente función:

logview()

{

ccze -A < $1 | less -R

}

Lo que hace la función es ejecutar ccze para que colorize el el archivo de log que le pasamos como argumento. La opción -A indica que la salida sea en modo raw que es la que acepta el paginador less, ya que ccze solo colorea pero no muestra los resultados. Luego mediante una tubería se lo pasamos less para que lo muestre y para que interprete los colores le pasamos la opción -R.

Solo basta recargar nuestro archivo .bashrc

# . .bashrc

o

# source .bashrc

y listo ya podemos usar la función creada como un comando para ver los logs a color.

# logview /var/log/mail.log

ccze tiene soporte para varios logs entre ellos syslog, messages, maillog y dmesg.

A continuación, una captura de cómo se ve el log de dmes con este pequeño truco

Links sobre el tema:

Pagina en francés que provee la función para colorear los logs

Esta semana tenía que hacer una instalación de Debian para un servidor, pero vaya problema, tenía el disco donde instalar pero no la máquina dónde hacerlo. La idea era instalar en una máquina y luego pasar el disco con la instalación al nuevo servidor que alguien estaba gestionando su compra. El tema era ganar tiempo, así que recordé que Debian se puede instalar en un sistema ya funcionando. Sencillo, se conecta el disco a una máquina con un Debian o cualquier Linux andando, se particiona el disco, se montan las particiones y se instala desde el sistema que está corriendo. Para no dar más vueltas les explico paso a paso cómo.

Creación de las particiones

En primer lugar debemos conectar el disco donde vamos a hacer la instalación en nuestra máquina en donde tenemos fucionado nuestro Debian o cualquier otra distribución de Linux.

Una vez hecho esto tenemos que particionar el disco a nuestro gusto teniendo en cuenta las particiones que tendrá nuestra nueva instalación. Para ello usamos fdisk, nos aseguramos de por lo menos crear una partición para el sistema y otra para la swap, aunque podemos crear las que nos parezcan necesarias.

No nos olvidamos de formatear las partciones y activar la swap.

# mk2fs -j /dev/sda1

# mkswap /dev/sda2

# swapon /dev/sda2

Ahora debemos crear un punto de montaje para nuestra partición raíz desde la cual trabajaremos.

# mkdir /mnt/instalacion

Y montamos allí nuestra partición raíz

# mount /dev/sda1 /mnt/instalacion

Si hubieramos creado varias partciones, por ejemplo para /home, /var, o /usr, entonces tendríamos que montarlas también. Una vez montada la partición raíz creamos en ella los directorios correspondientes y montamos en ellos las particiones que creamos previemante. Por ejemplo:

# cd /mnt/instalacion

# mkdir /home

# mount /dev/sda2 home/

Instalación de Debootstrap

El siguiente paso es obtener un sistema Debian muy básico. Debian provee un paquete que provee esta instalción básica, el paquete es debootstrap. Si nuestro sistema es un Debian no tenemos más que instalarlo con aptitude:

# aptitude install debootstrap

Ahora bien si nuestra instalación de Linux no es Debian lo mismo podemos conseguir instalar el paquete.

Creamos un directorio donde bajaremos el paquete y lo descompactaremos:

# mkdir /tmp/debootstrap

# cd /tmp/deboostrap

y obtenemos el paquete desde alguno de los repositorios de Debian:

# wget http://ftp.es.debian.org/debian/pool/main/d/debootstrap/debootstrap_0.3.3.2etch1_all.deb

En el ejemplo el sistema base que obtenemos es el correspondiente a un Debian version Etch.

Para descomprimir el paquete necesitaremos el programa ar. Si no lo tenemos lo, instalamos:

# apt-get install ar

y luego descomprimimos nuestro paquete recién bajado:

# ar -x debootstrap_0.3.3.2etch1_all.deb

luego hacemos

# cd /

# zcat /tmp/debootstrap/data.tar.gz |  tar xv

Con lo cual habremos instalado el contenido del paquete .deb en nuestro sistema. Ahora podemos usar el programa debootstrap aunque no estemos en un sistema Debian.

No nos queda nada más que ejecutarlo:

# /usr/bin/debootstrap --arch i386 etch /mnt/instalacion http://ftp.es.debian.org/debian

Como vemos tenemos que indicarle a debootstrap, la arquitectura (i386, en nuestro caso), la versión de Debian, el directorio donde está montada la partición raíz y un repositorio de dónde traer los paquetes. Y listo, ya tenemos nuestro sistema Debian base.

Creación de los archivos de configuración del sistema

Ahora tenemos que retocar el sistema, para eso vamos a hacer un chroot y “entrar” a nuestra nueva instalación:

# LANG=C chroot /mnt/instalacion /bin/bash

Si no se quieren perder, si tienen más de una terminal abierta y no confundir su sistema con el que está en el chroot, pueden modificar el prompt para saber dónde están:

# export PS1="[chroot]$PS1"

De esta forma el prompt reflejará que están trabajando bajo la raíz del nuevo sistema, dentro del chroot.

Lo primero que hacemos es crear el fichero /etc/fstab y montar las particiones que no hayamos montado si así lo decidimos en el particionado.

Un fstab base puede ser el siguiente. Desde luego debemos modificarlo según nuestras necesidades.

# /etc/fstab: static file system information.#

# file system    mount point   type    options                  dump pass

/dev/XXX         /             ext3    defaults                 0    1

/dev/XXX         /boot         ext3    ro,nosuid,nodev          0    2/dev/XXX         none          swap    sw                       0    0

proc             /proc         proc    defaults                 0    0

/dev/fd0         /media/floppy auto    noauto,rw,sync,user,exec 0    0

/dev/cdrom       /media/cdrom  iso9660 noauto,ro,user,exec      0    0

/dev/XXX         /tmp          ext3    rw,nosuid,nodev          0    2

/dev/XXX         /var          ext3    rw,nosuid,nodev          0    2

/dev/XXX         /usr          ext3    rw,nodev                 0    2

/dev/XXX         /home         ext3    rw,nosuid,nodev          0    2

Si ejecutamos mount -a, se montará cualquier partición que no estuviera montada.

Es necesario que el directorio /proc esté montado para seguir adelante. Si no se montó bien con mount -a, lo podemos hacer a mano (lo mismo para cualquier particion):

# mount -t proc /proc

Además creamos enlaces simbólicos a los dispositivos removibles, como por ejemplo el cdrom:

# cd /media# mkdir cdrom0

# ln -s cdrom0 cdrom

# cd /

# ln -s media/cdrom

Luego configuramos la zona horaria.

Editamos /etc/default/rcS según nuestras preferencias y luego corremos tzconfig

# tzconfig

y elegimos nuestra zona horaria.

Lo siguiente es configurar la red. Para ello necesitmos crear el archivo /etc/network/interfaces. Un archivo de ejemplo puede ser el siguiente:

# Configuramos la intefaz del loopback

auto loiface lo inet loopback# Si usamos dhcp

# auto eth0

# iface eth0 inet dhcp

# Si usamos una ip estática, este es un ejemplo:

# auto eth0# iface eth0 inet static

#     address 192.168.1.2

#     network 192.168.1.0#     netmask 255.255.255.0

#     broadcast 192.168.1.255

#     gateway 192.168.1.1

Si usamos dhcp, descomentamos la primera opción o si no la segunda parte y ponemos nuestra configuración de red.

En /etc/resolv.conf agregamos la dirección ip de nuestro servidor de nombres y el dominio por defecto.

search mi.dominio.com  nameserver 192.168.1.1

Además le ponemos nombre a nuestro nuevo sistema de la siguiente forma:

# echo "elservidor" > /etc/hostname

Creamos además el archivo /etc/hosts, y agregamos el nombre de nuestro servidor:

127.0.0.1 localhost elservidor # Si usamos ipv6 agregamos estas entradas::1     ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

ff02::3 ip6-allhosts

Como vamos a seguir instalando software en nuestro sistema, debemos agregar los repositorios que nos convengan. Por lo menos el repositorio principal y las actualizaciones de seguridad en /etc/apt/sources.list

deb http://ftp.es.debian.org/debian etch main deb http://security.debian.org/ etch/updates main

Para actualizar:

# apt-get update

El siguiente paso es instalar los locales, lo que nos permitirá tener un sistema en nuestro idioma

# aptitude install locales

# dpkg-reconfigure locales

Y en la pantalla que aparece, elegimos los locales que correspondan a nuestro idioma, en español hay que elegir es_ES, para que los caractéres salgan bien en pantalla.

Y para que nuestro teclado también esté en español instalamos el paquete console-data:

# aptitude install console-data

# dpkg-reconfigure console-data

Instalación del kernel

Todo muy bien hasta aquí, pero un pequeño detalle es que todavía nuestro sistema no tiene un kerenel instalado, algo un tanto importante, por lo tanto vamos a instalarlo.

Antes que nada instalamos el programa del gestor de arranque, ya que cuando se instala el kernel se corre este programa. Vamos a usar grub:

# aptitude install grub

Y creamos el archivo /etc/kernel-img.conf, que indica una serie de pasos que se deben seguir cuando se instala el paquete del kernel, como crear links al archivo del núcleo, actualizar grub, e instalar el initrd. El contenido es el siguiente:

# Kernel image management overrides# See kernel-img.conf(5) for details

do_symlinks = yes

relative_links = yes

do_bootloader = yes

do_bootfloppy = no

do_initrd = yes

link_in_boot = no

Como hay más de un kernel para elegir e instalar, podemos ver las opciones:

# apt-cache search linux-image

Elegimos el que más se adapte a nuestro sistema e instalamos:

# aptitude install linux-image-2.6.18-4-i386

Aunque la instalación del kernel crea los archivos de configuración de grub, el programa en sí no está instalado en el MBR, por lo tanto debemos instalarlo

# grub-install --root-directory /dev/sda1 --recheck /dev/sda

# update-grub

Debemos pasarle la opción –root-directory para que grub sepa en qué partición se encuentra el directorio /boot/grub y su archivo de configuración menu.lst

–recheck es para que chequee de nuevo los dispositivos, por si hemos particionado y grub no está al tanto de las nuevas particiones.

Y por útlimo le decimos que instale el cargador de arranque en el disco de la nueva instalación. Debemos tener cuidado y no instalarlo en el MBR de nuestro sistema que ya está andando.

Por último para que cuando instalemos nuevos kernels grub se actualice sin problemas volvemos a cambiar algunos parámetros en /etc/kernel-img.conf

Ponemos

do_bootloader  = No

y agregamos:

postinst_hook = update-grubpostrm_hook   = update-grub

Últimos retoques

Como último paso podemos retocar nuestra instalación para que no sea tan básica, de manera que se instalen los programas que más comunmente usamos:

# tasksel install standard

#aptitude clean

Y eso es todo. Si todo fue bien, entonces deberíamos tener un sistema Debian instalado y listo para correr. No queda más que reiniciar la máquina, configuar el equipo para que bootee desde el disco o la partición en que instalamos y ya podemos entrar a nuestro sistema. Usuario root y contraseña <enter> y ya podemos empezar a usarlo.

Links sobre este tema:

Instalar Debian GNU/Linux desde un sistema Unix/Linux – Howto oficial de Debian

Instalación de pkg-get

Primero que nada vamos a necesitar agregar software a nuestro Solaris que no viene en el DVD de serie. El software para Solaris se puede obtener ya compilado en formato de paquetes.

La herramienta para instalar paquetes en este sistema es pkgadd, que vendría a ser como el dpkg de Debian o el rpm de otras distros de Linux. Pero como usamos Debian y amamos apt-get queremos una solución un poco más cómoda e inteligente. La respuesta es pkg-get, que es el equivalente a apt-get pero para Solaris. pkg-get resuelve las dependencias automáticamente y descarga e instala los paquetes directo desde un repositorio por la red.

Para instalarlo obviamente vamos a necesitar de pkgadd

# pkgadd -d http://www.blastwave.org/pkg_get.pkg

Luego de aceptar todas las preguntas que nos hace pkgadd, tenemos que definir los repositorios desde los cuales vamos a descargar el software.

La opción más recomendable son los repositorios de www.blastwave.org, que contiene mas de 1700 paquetes de software en su mayoría open source. Todo el software de este repositorio se instala bajo /opt/csw. Por lo tanto modificamos el fichero de configuración de pkg-get:

#nano /opt/csw/etc/pkg-get.conf

Usamos nano, no porque nos guste, sino porque el vi que viene por defecto en Solaris es a mi gusto inusable. Luego lo arreglaremos.

Buscamos en www.blastwave.org/mirrors.php un mirror que este cerca o que sea rápido y lo definimos como sigue:

url=http://mirrors.sunsite.dk/csw/stable

Podemos usar la rama stable y la unstable, dependiendo de para qué vayamos a usar el equipo. Solo es necesario agregar una línea más con unstable o stable al final de la url.

Si estamos detrás de un proxy, lo configuramos:

http_proxy=http://proxy.mi.red.com:8080
export http_proxy ftp_proxy

Por último, podemos deshabilitar el chequeo de firmas y sumas md5, si nos sentimos confiados. Aunque nunca nadie sabe…

use_gpg=false
use_md5=false

Instalación de Vi mejorado

Ahora que tenemos pkg-get configuado lo podemos usar para instalar software. Lo primero que hacemos es instalar vi-enhanced, o vim.

# pkg-get install vim

Ahora bien si corremos vim nos daremos cuenta de que funciona igual que el vi que trae por defecto Solaris. Entre otras cosas la tecla backspace no funciona bien y las teclas de dirección (las de las flechas) no nos permiten movernos por el texto sino que imprimen caracteres en la pantalla. Para solucionarlo debemos crear un archivo de configuración para vim en el directorio personal de nuestro usuario. Si el usuario es root, entonces el directorio de usuario es “/” (Sí, “/”, Solaris no pone un “/root” para el superusuario).

# cd
# nano .vimrc

Y en .vimrc ponemos las siguientes líneas que solucionan los problemas anteriores del vim. Además activamos el coloreado de la sintaxis que es muy útil:

set nocp
set backspace=2
syntax on

Y listo, ya podemos usar vim como en Linux.

Cambiar la shell de root

Una de las cosas más molestas de Solaris cuando recién se instala es la shell. Por defecto Solaris no trae una shell moderna como bash sino la típica shell de Bourne o sencillamente “sh”. Esta shell no tiene ni histórico ni autocompletado y es bastante dura de usar.

¿Por qué viene por defecto? La razón es que es un ejecutable pequeño que no está enlazado dinámicamente con ninguna librería. De forma que si el sistema se vuelve inestable y no se puede montar alguna partición donde se alojan las librerías, lo mismo tendríamos una shell para acceder al sistema.

Nosotros vamos a hacer que se cargue bash como shell por defecto de root, siempre y cuando esté disponible, de manera que el sistema seguirá siendo a prueba de fallos. No tendremos que cambiar la shell en /etc/passwd, el valor lo dejaremos como está.

Para hacer el cambio, dentro del directorio del usuario editamos el archivo .profile, que es el archivo que lee la shell sh cuando se ejecuta. Será esta shell la que cargue bash de forma automática. Creamos el archivo con este contenido:

if [ -x /usr/bin/bash ]; then
SHELL=/usr/bin/bash
export SHELL
exec /usr/bin/bash
else
echo /usr/bin/bash not found using default shell of $SHELL
fi

Si salimos de la sesión y volvemos a entrar veremos que bash se carga automáticamente.

Un último detalle un tanto lamentable es que definiendo bash como shell para el entorno, no se puede iniciar el entorno gráfico. Cuando tratamos de ingresar desde el inicio gráfico de Solaris, este ser reinicia y no podemos acceder a Gnome o a CDE. Si definimos Bash para el usuario root, esto no es problema ya que usar el entorno gráfico con root no es buena opción; pero no deja de ser una solución poco elegante. Seguiré investigando para ver como solucionarlo.

Modificación del entorno de bash.

Hay algunas variables de entorno que controlan como funciona bash y que es muy útil definir.

En primer lugar debemos crear los archivos de configuración de bash, que son dos. En primer lugar .bash_profile, con el siguiente contenido:

source ~/.bashrc

Esto hace que se cargue el contenido de .bashrc que es el archivo donde guardamos las configuraciones personales para bash.

De seguro la más importante es el path, o sea los directorios donde la shell buscará los programas que se pueden ejecutar. Por defecto el path de Solaris es el siguiente:

/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/ucb

Que nos sirve si usamos el software oficial de Solaris. Pero como vamos a instalar software de blastware y también software libre que Sun provee que no se encuentra dentro de ese path, entonces tendremos que modificarlo. Ponemos:

export PATH='/usr/bin:/usr/sbin:/usr/openwin/bin:/usr/ucb:/opt/csw/bin:/usr/sfw/bin'

• /opt/csw/bin es el directorio donde están los binarios del software que instalamos con pkg-get, desde los repositorios de blastwave.
• /usr/sfw/bin es el directorio donde se ubican los binarios de software libre provisto por Sun como samba y wget.

ls en colores

El comando ls que provee Solaris no nos permite colorear la salida, así que vamos a solucionarlo de nuevo con una opción libre. Instalamos el paquete fileutils que nos provee un ls con colores.

# pkg-get install fileutils

Fileutils nos instalará el comando gdir que no es otra cosa que el ls que usamos en bash. Modificamos .bashrc para crear un alias de ls a gdir y habilitamos los colores. Agregamos lo siguiente:

export LS_OPTIONS='--color'
eval "`gdircolors`"
alias ls='gdir $LS_OPTIONS'
alias ll='gdir $LS_OPTIONS -l'
alias l='gdir $LS_OPTIONS -lA'

Bash Completion

Aunque bash nos completa de forma muy útil los paths y los nombres de los programas por defecto, hay algunas cosas que no nos completa como por ejemplo los argumentos de ciertos programas. Bash Completion viene a solucionar esto, y es muy útil con comandos como pkg-get o svcadm. Lo instlamos con pkg-get:

# pkg-get install bash-completion

Para que el autocompletado se cargue de forma automática, debemos agregarlo también en .bashrc:

source /opt/csw/etc/bash_completion

Cambio del paginador y alias para vi

Las páginas del manual son paginadas por defecto con more que es bastante molesto de usar. Lo cambiamos por less, modificando lo siguiente en .bashrc:

export PAGER=less

Creamos un alias para vi en .bashrc para que se llame automáticamente a vim:

alias vi='/opt/csw/bin/vim'

Prompt descriptivo y en color

Como último paso vamos a modificar el prompt para que entregue más imformación. Además le vamos a poner color para visualizarlo mejor. Agregamos a .bashrc:

export PS1="\[33[0;32m\][\u@\h:\W]\$\[33[0m\] "

explicamos qué es cada cosa:

• \[33[0;32m\] Es un carácter no imprimible que cambia el color del terminal a verde, así el prompt adquiere este color.
• \u Imprime el nombre del usuario logueado
• \h imprime el nombre de la maquina o hostname
• \W Imprime el nombre del directorio en el que estamos parado.
• \$ Si el usuario es root, imprime un “#”, de lo contrario imprime un “$”
• \[33[0m\] Con esta secuencia volvemos al color original de la shell para que no siga en color verde.

Nuestro prompt quedaría de la siguiente manera:

[root@servidor:etc]#

Esto es todo, ya tenemos un entorno en Solaris bastante más familiar y agradable que nos hace la vida más sencilla.

Esta vez se trata de armar una radio por Internet. Queremos que nuestra transmisión analógica se pueda escuchar por Internet. Para eso como siempre usamos Linux y nuestra queridad distribución Debian en su versión Etch (bueno o la que tengan a mano si no les gusta Debian). Si estamos hablando de radio por Internet, entonces estamos hablando de streaming.

¿Qué es el streaming?

El streaming de audio es sencillamente la transmisión de audio digitalizado y codificado que se reproduce en el cliente en vivo. O sea no hace falta descargar todo el archivo desde el servidor para escucharlo sino que se eschucha a medida que se descarga. El streaming es la técnica que utilizan las radios por internet, aunque también se aplica al video.

El formato en que se envían las transmisiones de audio suele ser el famoso mp3, pero también podemos codificar en otros formatos como por ejemplo ogg. Se puede hacer streaming de audio almacenado en archivos, por ejemplo temas musicales o podcasts que están almacenados en el servidor y se reproducen en el cliente bajo demanda. Pero también, y más interesante, es hacer codifcación en vivo del audio. O sea, en el servidor se toma la entrada de audio analógica, se codifica (en mp3 u ogg, etc.) y luego se envía por Internet para que los clientes escuchen nuestra “radio”. Este tipo de streaming es el que vamos a explicar.

Lo que hace falta para levantar un servidor de streaming en Linux

La figura del principio nos muestra qué hace falta para que nuestra radio suene en Internet usando Linux. Nos estamos refiriendo a software; pero obviamente si queremos que en nuestro equipo entre audio analógico debemos disponer de una placa de sonida que tenga una entrada de línea y que esté soportada por el sistema de audio de nuestro sitema operativo.

A continuación, los componentes:

Alsa

Alsa es el sistema de sonido de Linux. Aunque no es el único sistema de sonido que existe, sí es el más difundido y con más amplio desarrollo, y por supuesto soporta la mayor cantidad de hardware de audio.

Alsa se encarga de cargar los módulos del kernel necesarios para que funcione el sonido y los módulos que harán que la placa de sonido sea reconocida y funcione. Además Alsa presenta al sistema un dispositivo mezclador o mixer, que cumple la función de consola de mezclas. Al acceder al mixer podemos ajustar el volumen de los diferentes “canales”, por ejemplo el sonido de todo el sistema o master, el volumen del reproductor de cd o el del micrófono.

Una de las funciones del mezclador de sonido que más interesa a la hora de hacer streaming de audio en vivo es la que controla el dispositivo de grabación. En el mezclador se definen varias fuentes de audio que se pueden usar para grabar o capturar audio; por ejemplo el sonido que introducimos a la placa de audio por la entrada de línea, el de un micrófono, o el del cd de audio que está sonando. Todas estas fuentes de audio se pueden digitalizar, pero para ello hay que decirle al sistema de sonido de qué fuente queremos grabar. Otra opción, en el caso de que la placa de sonido lo soporte, es decirle al sistema de sonido que queremos grabar una mezcla de todas las fuentes de audio activas en el momento. Pero siempre hay que tener en cuenta que si no ponemos a grabar la fuente desde la que nos interesa capturar el audio, no podremos transmitir nada en nuestra radio.

Como en nuestro caso el audio es generado afuera del servidor y lo introducimos por la entrada de línea, tendremos que configurar el mezclador para que defina como dispositivo de grabación solo a la entrada de línea.

LAME y DarkIce

DarkIce es un programa fuente de streaming. Los programas fuentes se encargan de proveer el audio que el servidor de streaming ofrecerá a los clientes. Para esto se conectan al servidor de streaming con un usuario y contraseña en un puerto específico e inyectan el audio que ofrecen bajo lo que se llama un punto de montaje, que viene a ser un identificador del audio que están ofreciendo. Un servidor de streaming puede recibir audio de más de un programa servidor como DarkIce.

DarkIce se encarga de todo lo referente a la fuente del audio y la codificación del mismo. Entre otras cosas, en la configuración de DarkIce se debe especificar:

• La frecuencia de muestreo
• Los canales que tendrá el audio grabado (mono o estéro)
• El codec a usar (mp3, ogg, etc)
• El bitrate, o el ancho de banda que se usará para transmitir el stream de audio

Ahora bien, todo el trabajo de codificación no lo hace DarkIce, sino que este usa un programa externo para ello. Si se quiere transmitir en mp3, el programa es LAME, que es un encoder de mp3. LAME toma los parámetros de configuración que le pasa DarkIce y codifica el audio en mp3, luego se lo devuelve a DarkIce quien lo inyecta en el servidor de streaming.

Icecast2

Icecast2 es el programa de streaming propiamente dicho. Este servidor se encarga de gestionar las peticiones de los clientes que piden las transmsiones de audio. Icecast puede manejar varias transmisiones a la vez de distintas fuentes de audio. El programa trabaja en su propio puerto (el 8000) pero toda la transmisión la hace usando el protocolo http, por lo cual es bastante transparente a usuario, de forma que no hay que preocuparse de que proxys o gateways que pueda haber en el medio flitren la conexión.

Icecast levanta además una interfaz web desde la cual se puede administrar el servidor y ver los streams de audio disponibles.

Pasos para configurar una radio en Linux usando Debian Etch

Primero que nada debemos asegurarnos de que podemos manejar el audio en nuestro equipo. Necesitaremos hacer funcionar el sistema de sonido de Linux, Alsa. Si no lo tenemos instalado:

# apt-get install alsa alsa-base alsa-utils

Para configurar el sonido corremos el siguiente comando y seguimos las instrucciones:

# alsaconf

Este programa se encargará de detectar nuestra placa de sonido y configurar Alsa para que cada vez que inicie cargue los módulos necesarios en el kernel para que nuestra placa de sonido funcione.

Nos aseguramos también de que el servicio de sonido se levante cada vez que encendamos el equipo:

# rc-update add alsa default

La instalación de DarkIce y de LAME, requiere de un poco más de trabajo. Debido a las políticas de Debian con respecto a software que puede violar patentes LAME no está incluido en los repositorios oficiales y la versión de DarkIce que sí está incluida en los repositorios ha sido compilada sin soporte para mp3. Por lo tanto tendremos que buscar los paquetes necesarios para LAME y recompilar DarkIce con soporte para mp3.

Para instalar LAME, agregamos los repositorios de Debian multimedia a nuestro /etc/apt/sources.list

deb http://www.debian-multimedia.org etch main

Hacemos

# apt-get update

# apt-get install lame liblame-dev

Para DarkIce, nos aseguramos de tener algún repositorio con los fuentes de los paquetes en nuestro sources.list

deb-src http://ftp.debian.org/debian/ etch main contrib non-free

Luego hacemos

# apt-get build-dep darkice

Con lo que se descargarán las fuentes de DarkIce y se instalarán todos los paquetes necesarios para que podamos compilarlo.

Dentro del directorio de los fuentes de DarkIce que se generará, modificamos el archivo que indica cómo debe ser compilado el paquete para Debian. Configuraremos una opción para que incluya el soporte para mp3 a través de LAME

# vi darkice-0.17.1/debian/rules

Nos aseguramos de que esta línea quede así (con el parámetro --with-lame)

DEB_CONFIGURE_EXTRA_FLAGS := --prefix=/usr --sysconfdir=/usr/share/doc/darkice/examples --with-lame

Para compilarlo y empaquetarlo hacemos:

# apt-get source --build darkice

Instalamos luego el archivo .deb resultante

# apt-get install darkice_0.17.1-3_i386.deb

y listo, ya tenemos DarkIce con soporte para mp3.

Como último detalle debemos recordar no actualizar DarkIce desde los repositorios oficales, para no perder los cambios, o recompilarlo de la misma manera cada vez que aparezca una nueva versión.

Ahora que el software está instalado vamos a configurarlo. Empezamos por Icecast2. Modificamos /etc/icecast2/icecast.xml

<authentication>
<!-- Sources log in with username 'source' -->
<source-password>sourcepass</source-password>
<!-- Relays log in username 'relay' -->
<relay-password>hackme</relay-password>


<!-- Admin logs in with the username given below -->
<admin-user>admin</admin-user>
<admin-password>adminpass</admin-password>
</authentication>

Definimos dos usuarios, con sus respectivas contraseñas. Por un lado el usuario del programa fuente; luego configuraremos DarkIce con esa contraseña para que se conecte a Icecast2. Por otro lado el usuario administrador, que es el usuario que utilizaremos para controlar Icecast2 por la interfaz web que posee. Con esta configuración nos basta para que Icecast2 funcione como queremos.

La mayor parte de la configuaración de nuestro stream de audio la tendremos que definir en la configuración de DarkIce.

DarkIce no se instala como un servicio, y no trae un archivo de configuración por defecto, por lo cual tendremos que copiar el que viene en la documentación y modificarlo a nuestro gusto

# cp /usr/share/doc/darkice/examples/darkice.cfg /etc

El archivo es de tipo .inf y se divide en una sección general, otra que define la entrada de audio (input) y varias secciones de ejemplo con la configuración para diferentes clases de servidores de streaming de audio. Como nos interesa Icecast2, borramos todas las que no se ajusten a este servidor.

Las diferentes secciones deberían quedar así:

[general]
duration = 0

bufferSecs = 5

reconnect = yes

Nos interesa el parámetro duration, donde ponemos como valor “0″ (cero) para que DarkIce no ponga duración a la transmisión, sino que sea indefinida.

[input]
device = /dev/dsp
sampleRate = 44100
bitsPerSample = 16
channel = 2

La opción sampleRate indica el muestreo que se hará sobre el audio al codificarlo. Mientras más muestras por segundo se tomen del audio para pasarlo de analógico a digital, mejor será la calidad del sonido. Pero debemos tener en cuenta que si subimos la calidad también aumentará la cantidad de datos codificados, y quizás tengamos que aumentar el bitrate o ancho de banda de la transmisión.

Si queremos que nuestro audio sea codificado y transmitido en estéreo debemos configurar el valor de channel en 2.

[icecast2-0]
bitrateMode = abr

format = mp3

bitrate = 128

server = localhost

port = 8000

password = sourcepass

mountPoint = fmlinux

name = Radio GNU/Linux

description = Una radio especial

url = http://www.radio-linux.com

genre = radio

public = yes

En esta sección configuramos la conexión con el servidor Icecast2. Ponemos la dirección ip o nombre de nuestro servidor que en nuestro ejemplo funciona en el mismo host. El puerto por defecto es el 8000, pero dependiendo de la configuranción podría ser cualquier otro.

El password debe coincidir con el que pusimos en la configuración de Icecast2 para el programa fuente. Definimos también que el formato sea mp3 para que DarkIce sepa que encoder utilizar (otra opción es codificar en ogg). El punto de montaje, es el nombre con el que se identificará a nuestra transmisión en el servidor de streaming, por eso debemos ponerle un nombre que sea descriptivo.

El bitrate, se refiere al ancho de banda que va a necesitar el stream de audio para ser transmitido. Si queremos más calidad podemos aumentar el bitrate, pero desde luego no podemos limitarlo indefinidamente, ya que necesitaremos disponer de mucho ancho de banda de subida en nuestro servidor y de bajada en el cliente.

Antes de poner todo a andar debemos asegurarnos de que en el mezclador del sistema de sonido (Alsa) la entrada de línea sea el dispositivo elegido para grabar. Podemos usar alsamixer para configurar de forma gráfica el audio. Dentro de alsamixer presionamos F4 y se nos muestran los controles de grabación.

Para nuestra tarjeta de sonido (una Intel High Definition Audio), estos son los controles que se nos muestran:

Como vemos, tenemos que definir dos cosas: Que la entrada de línea este grabando, identificado en rojo con la palabra CAPTUR (de no ser así, con la barra espaciadora lo cambiamos), y por otro lado que el nivel del volumen para la captura esté lo suficientemente alto.

Alsa guarda los valores del mezclador y los reestablece cada vez que se inicia. De cualquier forma podemos usar el comando amixer en algún script si queremos poner a mano los valores del mezclador. Aunque hay que reconocer que el comando amixer es bastante más difícil de utilizar que alsamixer, ya que no es gráfico.

Si todo ha ido bien, solo tenemos que levantar los servicios. Para levantar Icecast2 primero editamos /etc/default/icecast2 y habilitamos el servicio.

ENABLE=true

luego hacemos

# /etc/init.d/icecast2 start

DarkIce no corre como servicio por lo que tendremos que ejecutarlo a mano e indicarle dónde buscar el archivo de configuración. Agregamos un “&” al final para que corra en background.

# darkice -c /etc/darkice.cfg &

Luego podemos crear un script que corra al inicio del sistema para que se inicie DarkIce con estos parámetros.

Para verificar que todo anda, nos conectamos al servidor web que levanta Icecast2 usando un navegador.

http://localhost:8000

Desde allí podremos ver las transmisiones que el servidor ofrece y si entramos en la parte de administración con el password que pusimos en la configuración de Icecast2, podremos ver los programas fuentes conectados.

Pero como la prueba definitva para saber si el servidor funciona es escuchar el audio, nos conectamos con un cliente al servidor. Usamos cualquier programa de reproducción de audio que soporte streaming (algunos: xmms, winamp, quod-libet, rythmbox, vlc, kaffeine). Nosotros usaremos mplayer, ya que ni siquiera tendermos que abrir la parte gráfica. Tenemos en cuenta que debemos usar el puerto 8000 e indicar el punto de montaje (en nuestro caso habíamos definido fmlinux).

# mplayer http://www.radio-linux.com:8000/fmlinux

Si todo va bien, deberíamos ver como después de unos segundos que mplayer tarda en cargar el búfer de audio, nuestra transmsión suena en el equipo cliente.

Esto es todo, ahora podemos dedicarnos a sintonizar nuestra radio y a gastar ancho de banda en ociosidades y demás que para eso pasamos tanto tiempo configurandolo…

Links sobre el tema

Página oficial de Icecast2

Página oficial de DarkIce

Página oficial de Alsa

Página oficial de LAME 

Blog con detalles para recompilar DarkIce con soporte Mp3 

Qué es MSP

Las últimas versiones de Sendmail dividen el servicio de Sendmail en dos partes, el MTA y el MSP. El MTA de seguro lo conocemos, es el famoso Mail Transport Agent, pero el MSP? Bueno con MSP nos referimos Mail Submission Program. Pero, ¿por qué la división?

La respuesta tiene que ver con un RFC, una de esas tantas normas que gobiernan Internet. Según el RFC nº 2476 el servicio de correo electrónico debe dividirse claramente en dos partes: MTA y MSP y la división tiene que ver con el tipo de conexión que lleva a cabo el servidor

MTA: Conexión servidor – servidor

Si el servidor se está comunciando con otro servidor de correo (otro MTA) para tramitar el envío del los correos electrónicos, entonces decimos que funciona como MTA, o sea agente de transferencia de correo. Puede ser que para entregar el correo, Sendmail (en nuestro caso) tenga que comunicarse con un servidor de correo, pero también puede ser que el mensaje tenga que pasar por varios servidores MTA antes de llegar a destino; lo que comunmente se llama relaying. El relaying por lo tanto lo hacen solo los servidores MTA.

MSP: Conexión cliente – servidor

Si la conexión se da entre el cliente de correo electrónico (también llamado MUA) y el servidor que luego lo se encargará de la transferencia (Sendmail) entonces se dice que el servidor está actuando como MSP o Mail Submission Program. La diferencia es que aquí el servidor solo acepta un mensaje de un cliente y lo pone en la cola de salida. Luego cumpliendo la función de MTA, se comunicará con otros servidores de correo para que el mensaje llegue a su destino.

En versiones anteriores de Sendmail que no seguían el RFC nº 2476, se levantaba un sólo servidor que actuaba como MTA y MSP indistintamente. En las últimas versiones de Sendmail, si se activa el MSP, veremos que incluso tiene asignado un puerto específico, el 587, para que escuche las conexiones de los clientes de correo electrónico. Además todo el correo que es generado localmente dentro del servidor, ya sea por un cliente de correo, por el comando mail, el plugin vacation o los mails que envía el mismo sistema, es enviado a Sendmail-MSP. Debido a esto, si no activamos el servidor MSP no podremos enviar correo localmente.

En teoría si configuramos nuestro cliente de correo para que se comunique con su servidor saliente en el puerto 587, tiene que funcionar sin ningún problema. En la práctica esta constumbre no está difundida y se sigue configurando el puerto 25 para inyectar el correo del cliente en el servidor, aunque según el RFC este puerto deba usarse solo para conexiones entre MTA’s.

El por qué de la separación

La pregunta es por qué hacer esta separación cuando toda la vida los servidores no han hecho distinción entre las conexiones entre servidores y las conexiones entre cliente y servidor. Una lectura del RFC implicado nos dice que, entre otas cosas, separar el MTA del MSP hace que sea más fácil implementar pólitcas de seguridad contra el correo no deseado y el relaying no autorizado.

Configurando Sendmail para que levante el MSP

La línea que hay que editar para que levante el MSP es solo una dentro de sendmail.mc

DAEMON_OPTIONS(`Family=inet, Name=MSP-v4, Port=submission, Addr=127.0.0.1')dnl

Si dejamos el parámetro Addr en 127.0.0.1, entonces el MSP solo escuchara en la interfaz local y enviará los correos generados localmente. Los clientes de correo o MUA’s seguirán conectándose al puerto 25.

Si queremos tener activo el MSP junto con el MTA, debemos tener cuidado de no comentar la línea que se refiere al MTA. La mayoría de los manuales para configurar Sendmail nos dicen que lo primero que debemos hacer en una configuración estándar es comentar la siguiente línea:

DAEMON_OPTIONS(`Family=inet, Name=MTA-v4, Port=smtp, Addr=127.0.0.1')dnl

Porque de lo contrario Sendmail escuchará solo en la interfaz local.

Pero si comentamos esta línea y dejamos descomentada la del MSP, Sendmail entenderá que solo debe levantarse como MSP y solo escuchará en el puerto 587. Entonces es más correcto dejar descomentada la línea pero indicarle que escuche en todas las interfaces.

DAEMON_OPTIONS(`Family=inet, Name=MTA-v4, Port=smtp, Addr=0.0.0.0')dnl

El 0.0.0.0 le dice a Sendmail que escuche como MTA en todas las direcciones de nuestro servidor. Claro está que podemos poner una ip específica si queremos que nuestro servidor escuche en una solo ip como MTA. Lo mismo vale para la línea que configura Sendmail como MSP.

Como siempre hay que recordar que debemos compilar los archivos .mc después de editarlos y reiniciar el servicio para que tome los cambios.

# make

#/etc/init.d/sendmail restart

Dos detalles más que agregar. La configuración del MSP es manejada por el archivo submit.mc; generalmente no hay que tocar nada dentro de este archivo. Por otra parte la cola de los correos de Sendmail-MTA está en /var/spool/mqueue mientras que la de Sendmail-MSP está en /var/spool/client-mqueue

Resta decir que no encontré si los demás MTA’s – MSP’s disponibles (Postfix, Qmail, Exim, etc.) se atengan a la RFC mencionada. Parece ser que el cambio no es radical, pero que afecta a la configuración de Sendmail, afecta.

Espero que esta información les sea de utilidad a aquellos que todvía usan Sendmail y se encuentren desorientados con estos pequeños cambios.

Links sobre el tema

RFC 2476 – Message Submission

Página de Sendmail sobre submit.mc

Página de Sendmail explicando el por qué se Sendmail-MSP

Plantearemos un ejemplo en el que nuestro disco iSCSI contiene una partición con los datos de los recursos compartidos de un servidor Samba. Para ello necesitaremos hacer lo siguiente:

• Instalar y configurar el iniciador iSCSI
• Conectar automáticamente el recurso iSCSI
• Particionar y formatear el disco iSCSI
• Montar automáticamente las particiones dentro del disco cada vez que se conecte
• Desmontar las particiones y desconectar el recurso iSCSI cuando el sistema se apague

Instalación de open-iscsi

Lo primero que vamos a hacer es instalar el software iniciador. En Linux contamos con varios iniciadores iSCSI, sin embargo el más usado es open-iscsi, además está dentro de la paquetería de Debian. Lo instalamos

# apt-get install open-iscsi

Esto nos instalará un script de inicio que carga los módulos y lanza un programa que controla el iniciador (iscsid), y un programa para configurar nuestro iniciador (iscsiadm). Los módulos para iSCSI ya están presente en los kernels actules (desde el 2.6.18 en adelante) por eso no se incluyen en el paquete de open-iscsi.

Lo primero que debemos hacer es iniciar el servicio

# /etc/init.d/open-iscsi start

Configuración de open-iscsi

La configuración de open-iscsi se realiza a través del comando iscsiadm y la misma se guarda en una base de datos. Si queremos cambiar algún parámetro de la configuración tenemos que hacerlo a través de iscsiadm.

Detección del target

En primer lugar tenemos que indicarle a iscsiadm que detecte nuestro target iSCSI y lo agregue a su base de datos. Hay que aclarar que iscsiadm tiene tres formas de operación

discovery: En este modo se pueden descubrir targets y agregarlos a la base de datos.

node: En este modo se administran los targets ya descubiertos y se pueden visualizar datos acerca de estos nodos, así como conectarse a ellos.

session: En este modo se administran los targets a los que se está conectados (en los que se ha hecho login).

Para descubrir nuestro target usamos obviamente “discovery“

# iscsiadm -m discovery -t sendtargets -p 192.168.1.110
192.168.1.110,1 iqn.2005-02.au.com.empresa:san.200G.samba

Con lo que le indicamos a iscsiadm que descubra los targets que le ofrece el portal ubicado en 192.168.1.110. El método que usa para descubrirlo es “sendtargets“, que es el método soportado más estable a la fecha (existen otros métodos, como por ejemplo uno que resuelve nombre de targets).

Como vemos descubrió el target que instalamos anteriormente.

Por lo cual, si hacemos solo:

# iscsiadm -m discovery
192.168.1.110:3260 via sendtargets

Vemos que la información del servidor iSCSI target descubierto quedó almacenada en la base de datos de iscsiadm

Ahora, si queremos saber cuál es la información que se almacenó sobre el target descubierto, tenemos que operar en modo nodo

# iscsiadm -m node --targetname iqn.2005-02.au.com.empresa:san.200G.samba -p 192.168.1.110
node.name = iqn.2005-02.au.com.empresa:san.200G.samba
node.transport_name = tcp
node.tpgt = 1
node.active_conn = 1
node.startup = manual
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.auth.username =
node.session.auth.password =
node.session.auth.username_in =
node.session.auth.password_in =
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
...

Configuración de la autenticación

Si el target tiene configurada la autenticación, para pedir al iniciador un usuario y una contraseña, entonces debemos configurar esa información en nuestro iniciador. Para ello también usamos iscsiadm y modificamos la información almacenada para el target ya descubierto.
# iscsiadm -m node --targetname iqn.2005-02.au.com.empresa:san.200G.samba -p 192.168.1.110 -o update -n node.session.auth.username -v usuario-iniciador
# iscsiadm -m node --targetname iqn.2005-02.au.com.empresa:san.200G.samba -p 192.168.1.110 -o update -n node.session.auth.password -v clave-iniciador

El comando ahora varía porque include la opcion “-o update“, lo que indica que la operación que vamos a llevar a cabo sobre el registro del nuestro target es de actualización de la configuración.

La opción “-n“, indica el registro que vamos a actualizar, que como se puede ver lo hemos tomado de las salida del mismo comando pero sin la opción de actualización. Mientras que con “v” indicamos el valor que debe tener dicho registro. De manera que la configuración quedaría así:

node.session.auth.username=usuario-iniciador
node.session.auth.password=clave-iniciador

Obviamente, el usuario y la clave deben corresponder con los que configuramos en el servidor iSCSI.

Login en el dispositivo

Ahora que la información del target ya está configurada, podemos empezar a usarlo. Para ello debemos hacer login o autenticarnos en el target.

# iscsiadm -m node -targetname iqn.2005-02.au.com.empresa:san.200G.samba -p 192.168.1.110 -l

La opción “-l” indica que queremos hacer login en el target. Esto significa que el disco iSCSI estará disponible como un dispositivo de hardware más en nuestro servidor. Para comprobar si el disco iSCSI se detecto y se “conectó” al equipo, basta con ver la salida de dmesg

#dmesg
SCSI device sda: 390620475 512-byte hdwr sectors (199998 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
SCSI device sda: 390620475 512-byte hdwr sectors (199998 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
sda: sda1
sd 1:0:0:0: Attached scsi disk sda

En el ejemplo el disco iSCSI se detectó y se “conectó” al equipo como un disco SCSI más. También notamos que para el sistema nuestro disco iSCSI no se diferencia de un dsico SCSI conectado físicamente.

Creación de particiones y formateo.

Aunque el disco iSCSI ya está conectado, no es usuable hasta que definamos particiones en él y las formateemos en un sistema que el kernel maneje. Para ello podemos usar fdisk y mkfs en cualquiera de sus variantes. La información de dmesg que obtuvimos anteriormente nos indica que el disco se reconoció como /dev/sda

# fdisk /dev/sda

Para nuestro ejemplo creamos una sola partición con todo el espacio (/dev/sda1) y la formateamos como ext3:

# mkfs.ext3 /dev/sda1

Montaje automático del dispositivo de hardware iSCSI

Como último punto relacionado con la configuración del iniciador, deberíamos definir que se haga login al target y se conecte el disco automáticamente cada vez que se inicie el servicio open-iscsi, de manera que no tengamos que hacerlo a mano luego de que nuestro sistema inicie. Volvemos a utilizar iscsiadm para modificar el parámetro que maneja esta opción:

# iscsiadm -m node -targetname iqn.2005-02.au.com.empresa:san.200G.samba -p 192.168.1.110 -o update -n node.conn[0].startup -v automatic

Luego de esto, si hacemos

# /etc/init.d/open-iscsi restart

El disco iSCSI debería ser detectado automáticamente y conectado al equipo.

Montaje automático del filesystem

En nuestro ejemplo queremos que el disco iSCSI sea usado por un servicio, en este caso para almacenar los datos de usuarios que compartiremos con Samba. Por ello, necesitamos no solo que el disco iSCSI se conecte automáticamente sino que también las particiones dentro del disco se monten al inicio para que estén disponibles para el servicio que las usará.

En los sistemas Linux, el fichero /etc/fstab indica qué particiones deben ser montadas en el inicio, dónde y con qué opciones.

Identificación del dispositivo de hardware.

Para poder indicarle al sistema automáticamente qué partición debemos montar, tenemos que saber el dispositivo que apunta a dicha partición. En los ejemplos anteriores vimos que al iniciarse el servicio open-iscsi nuestro disco iSCSI se detectó como /dev/sda y por lo tanto la partición dentro de este disco es /dev/sda1.

El problema que se presenta es que los nombres que se dan a los dispositivos iSCSI no son estáticos y pueden variar cada vez que se reinicie el equipo. Si tuvieramos más de un disco iSCSI conectado al equipo, estos pueden ser cargados en distinto orden y por lo tanto los nombres no serían consistentes.

Por ejemplo, puede ser que dos discos iSCSI, uno de 100 Gb y otro de 200 Gb se detectaran como /dev/sda y /dev/sdb respectivamente; pero que luego de reiniciar el servidor, el de 100 Gb se conectara como /dev/sdb y el de 200 Gb como /dev/sda.

También pudiera suceder que un dispositivo usb conectado al equipo tomara el nombre /dev/sda, con lo que el nombre de nuestro dispositivo iSCSI tomaría otro nombre.

Por ello es necesario buscar una forma de referirnos a nuestro dispositivo de forma estática. Afortunadamente hay una forma de solucionarlo. El programa Udev es el encargado de crear los nodos de dispositivos conectados al sistema (archivos de dispositivos que se crean en /dev), darles un nombre, y crear links simbólicos para referirse a los dispositivos de más de una forma. Las últimas versiones de Udev crean links simbólicos persistentes a los dispositivos iSCSI.

El comando udevinfo nos dice qué links creó Udev para nuestro dispositivo.

# udevinfo --query symlink --name /dev/sda1
disk/by-id/scsi-149455400000000000000000001000000980b00000d000000 disk/by-path/ip-192.168.1.110:3260-iSCSI-iqn.2005-02.au.com.empresa:san.200G.samba-lun-0 disk/by-uuid/3c5c1fc8-cec1-41d4-8b92-11becd5f4832

Udevinfo nos muestra tres links simbólicos que creó en /dev. De manera que podemos referirnos a nuestro dispositivo por su nodo o nombre en /dev (en el ejemplo /dev/sda1) o usando cualquiera de estos tres links creados por Udev. De estos links, los dos útlimos nos son de utilidad porque identifican unívocamente a nuestro disco.

El primero está creado usando el path, que en el caso incluye el ip del servidor iSCSI, el puerto, el nombre del target, y el identificador de la partición (lun-0).

El segundo se crea a partir del uuid del disco, que es un identificador único que se asigna a la partición cuando es creada, y que por ende se borra solamente si eliminamos la partición. El uuid de nuesrtra partición según udevinfo es:

3c5c1fc8-cec1-41d4-8b92-11becd5f4832

Teniendo esta información, ya sabemos qué nodo en /dev (o qué link simbólico) tenemos que usar en nuestra entrada en /etc/fstab. En nuestro caso vamos a utilizar la identificación por path, usamos por lo tanto el siguiente link simbólico para el dispositivo:

/dev/ disk/by-path/ip-192.168.1.110:3260-iSCSI-iqn.2005-02.au.com.empresa:san.200G.samba-lun-0 /datos auto rw 0 0

Sin embargo si reiniciamos el servidor, vemos que el disco iSCSI no es montado y que el sistema da un error diciéndonos que el dispositivo no existe. La razón es simple: el script que monta las particiones en /etc/fstab es cargado antes de que la red y que el servicio iniciador open-iscsi. Por lo tanto el dispositivo es creado luego y por eso no se monta.

La documentación del comando mount nos dice que existe una opción de montaje para discos en red. La opción es “_netdev“. Esta opción indica que la partición no debe ser montada con las demás, sino que se deja sin montar para que un script posterior lo haga una vez que la red esté disponible.

En Debian el script que se encarga de montar este tipo de particiones es /etc/init.d/mountnfs.sh

Este script es ejecutado inmediatamente después de que la red está configurada y operando (es llamado dentro de /etc/network/if-up.d). El script está hecho para montar principalmente recursos nfs o samba por la red. Sin embargo al mirar el script vemos que no nos sirve para dispositivos iSCSI, porque entre el inicio de la red y el montado del disco iSCSI, necesitamos que se inicie el servico open-iscsi, y este script no provee esta opción.

De nuevo Udev nos provee un método para solucionar este problema. Además de nombrar dispositivos, Udev permite que se ejecuten programas una vez que un dispositivo es reconocido y conectado al sistema. En este caso, tenemos que decirle a Udev que ejecute el comando mount una vez que el disco iSCSI es reconocido y conectado.

De manera que la forma en que se monta nuestro disco, tomando en cuenta el sistema de inicio de Linux, es la siguiente:

1. Se montan los sistemas de archivos que no dependen de la red
2. Se configura y levanta la red
3. Se levanta el servicio iniciador open-iscsi
4. open-iscsi conecta el disco iSCSI
5. Udev reconoce un nuevo dispositivo y corre un comando para montar las particiones dentro de él.

La configuración de Udev funciona en base a reglas. Estas reglas comparan que la información sobre el hardware conectado coincida con ciertos valores y si es así, crean el nodo del dispositivo con cierto nombre o ejecutan algún programa.

En nuestro caso debemos obtener los valores que Udev recibe de nuestro dispositivo remoto e identificar uno que nos diga que el dispositivo es un disco iSCSI. Para ello volvemos a usar udevinfo

# udevinfo -q env -n /dev/sda
ID_VENDOR=IET
ID_MODEL=VIRTUAL-DISK
ID_REVISION=0
ID_SERIAL=1494554000000000030303030303100000000000000000000
ID_SERIAL_SHORT=494554000000000030303030303100000000000000000000
ID_TYPE=disk
ID_BUS=scsi
ID_PATH=ip-192.168.1.110:3260-iscsi-iqn.2005-02.au.com.empresa:san.200G.samba-lun-0
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=3c5c1fc8-cec1-41d4-8b92-11becd5f4832
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

El comando interroga a Udev y le dice que muestre todos los valores del tipo “env” para el dispositivo /dev/sda, o sea, nuestro disco iSCSI.

Nos interesa el valor “ID_PATH“, porque su valor contiene la palabra “iscsi”.

Creamos el archivo /etc/udev/rules.d/z99_open-iSCSI.rules con la siguiente línea

ENV{ID_PATH}=="*iscsi*", RUN+="/bin/mount -a -O _netdev"

Esta regla es leída por Udev cada vez que se conecta un dispositivo nuevo al sistema. Lo que hace es verificar que el valor “ID_PATH” del dispositivo contenga la cadena “iscsi”, si es así, el dispositivo conectado es del tipo iSCSI y por lo tanto corre el comando mount.

Como se puede ver, mount se llama con dos parámetros:

“-a” para que trate de montar lo que encuentre en /etc/fstab

“-O _netdev” para que solo monte las entradas de /etc/fstab que tengan marcada la opción “_netdev“

Como la entrada en fstab para nuestro disco iSCSI contiene la opción “_netdev“, será montado automáticamente.

Si hacemos la prueba y reiniciamos el servicio open-iscsi, veremos que en cuanto Udev detecta el nuevo disco iSCSI, monta la partición que creamos en él.

Nota 1: Es importante que el archivo de la regla de Udev tenga en su nombre un número alto, para que sea ejecutada en último lugar; de manera que primero se le de un nombre al dispositivo y se creen los links simbólicos correspondientes.

Nota 2: Hay que tener en cuenta que esta regla montará cualquier recurso en /etc/fstab_netdev“, sea o no iSCSI. que tenga la opción “

Nota 3: Para entender más cómo crear reglas de udev, se puede consultar esta excelente guía

Desmontaje automático

Desmontar los sistemas de archivos alojados en un disco iSCSI de forma correcta es importante para mantener la integridad de los datos almacenados en ellos. Hay que recordar que las particiones en un disco iSCSI deben ser desmontadas mientras el servicio open-iscsi esta corriendo; si detenemos el servicio open-iscsi, el disco se desconectará del equipo y por lo tanto cuando tratemos de desmontar alguna partición en él, no solo obtendremos un error sino que hasta podríamos perder datos valiosos.

Por lo tanto, debemos asegurarnos de que cuando apaguemos o reiniciemos el servidor, nuestras particiones sean desmontadas correctamente.

Debian Etch (4.0), no tiene ningún script que desmonte las particiones en un disco iSCSI. Por lo tanto, tendremos que crear un script que lo haga automáticamente. La secuencia para hacerlo correctamente, teniendo en cuenta las dependencia que hay entre servicios, es la siguiente:

1. Detener cualquier programa servidor que utilice los discos iSCSI conectados
2. Desmontar las particiones en los discos iSCSI
3. Detener el servicio iniciador open-iscsi
4. Detener el servicio de red

Si no se sigue ese orden, lo más probable es que obtengamos algún error.

Para ello creamos el siguiente script, que es solo una modificación del script /etc/init.d/umountnfs.sh de Debian, pero adaptado para el servicio iSCSI:

#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin
. /lib/init/vars.sh
. /lib/lsb/init-functions

do_stop() {
DIR=”"
while read DEV MTPT FSTYPE OPTS REST
do
if echo $OPTS | grep “_netdev” >/dev/null
then
DIR=”$MTPT $DIR”
fi
done</etc/mtab

if [ $DIR ]
then
[ "$VERBOSE" = no ] || log_action_begin_msg “Unmounting iSCSI filesystems”
umount $DIR
ES=$?
[ "$VERBOSE" = no ] || log_action_end_msg $ES
fi

}
case $1 in
start)
;;
restart|reload|force-reload)
echo “Error argument ‘$1′ no supported” >&2
exit 3
;;
stop|”")
do_stop
;;
*)
echo “Usage: umount-iscsi.sh [start|stop]” >&2
exit 3
;;
esac

Lo que hace el script es recorrer línea por línea el archivo /etc/mtab (este archivo tiene líneas idénticas a las de fstab pero solo para los sistemas de archivos que están montados en el momento), y busca aquellas en las que aparezca la opción “_netdev“, entonces desmonta la partición correspondiente a esa línea.

Una vez creado este archivo, le damos permiso de ejecución y lo copiamos a /etc/init.d.

# chmod u+x umount-open-iscsi.sh
# cp umount-open-iscsi.sh /etc/init.d/

Luego debemos agregar este script a los niveles de ejecución de apagado y reinicio del servidor. En Debian estos niveles son 0 y 6 respectivamente, y se usa el comando update-rc.d para agregarlos.

# update-rc.d umount-open-iscsi.sh stop 20 0 6 .

Lo que hace este comando es crear un link simbólico a nuestro script en los directorios /etc/rc0.d y /etc/rc6.d, con un identificador igual a 20 para indicar el órden en que debe ser ejecutado.

Nota: Hay que tener en cuenta que este script desmontará cualquier recurso que encuentre montado con la opción “_netdev“, esto puede incluir recursos smb o nfs.

Como en Debian, el servicio Samba (que en nuestro ejemplo es el programa que usará el disco iSCSI) tiene un identificador igual a 19 para el apagado, el servicio se apagará antes de que se desmonten las particiones en el recurso iSCSI, lo cual es correcto. Si no fuera así tendríamos que modificar el link simbólico del servicio que use el disco iSCSI, para que se apague antes de que se ejecute el script para desmontar el filesystem.

Ahora bien en Debian, el servicio open-iscsi tiene un identificador igual a 20 en el apagado. Para asegurarnos de que open-iscsi no se apague hasta que no se hayan desmontado las particiones en los discos iSCSI, cambiamos el identificador a un número más alto para que el apagado se ejecute después.
Esto debemos hacerlo en los niveles de ejecución 0 y 6, o sea en los directorios /etc/rc0.d y /etc/rc6.d

# mv K20open-iscsi K21open-iscsi

El servicio de red se apaga después, por lo tanto no tenemos que modificarlo.

Este es el último paso y si todo sale bien tendremos nuestro servidor pereparado para conectar a discos iSCSI. A probar ya comentar.

Links sobre el tema:

Post anterior: iSCSI explicado

Post anterior: Instalción de un servidor o target iSCSI

Página oficial del proyecto open-iscsi

Creación de reglas para Udev

Dentro de Linux hay unas cuantas soluciones software para montar un servidor o target iSCSI. La más recomendada es Linux iSCSI Enterprise Target. Las razones son, que a la fecha, es la versión más potente, con activo desarrollo y tiene como ventaja que no hay que recompilar el kernel para poder usarla.

Veamos como podemos instalar un servidor o target como se le menciona en la “jerga” iSCSI. Los pasos son los siguientes:

Verificación de la versión del kernel

iSCSI Enterprise Target funciona solo sobre el kernel 2.6.14 o superior. Por eso si nuestro kernel es anterior, entonces tendremos que actualizarlo, o en última instancia, compilar una versión más reciente.

En Debian Etch la versión es superior. Lo mismo siempre podemos hacer

#apt-get install linux-image

para actualizar a la última versión del kernel.

Instalación del servidor

IET (iSCSI Enterprise Target) no está disponible como un paquete para Debian, por eso tendremos que bajarnos los fuentes y compilarlos. La buena noticia es que es un programa muy pequeño y que la instalación nos deja todo para que funcione bajo Debian.

Descargamos IET y lo descomprimimos

# tar -xzvf iSCSItarget-0.4.15.tar.gz
# cd iSCSItarget-0.4.15

El README nos dice que necesitaremos los fuentes de nuestro kernel para poder compilar los módulos que IET debe cargar para funcionar. De esto también comprendemos que cada vez que actualicemos el kernel será necesario recompilar IET para que cargue módulos que sean compatibles (Está previsto que haya soporte nativo para targets iSCSI en el kernel a futuro). Además también necesitamos las librerías de desarrollo de ssl

# apt-get install linux-source libssl-dev

Luego basta hacer

#make
#make install

Con esto se compilarán los módulos del kernel y el servidor iSCSI (ietd). Además se instalará la documentación, los scripts de inicio y los archivo de configuración.

Configuración del target

La configuración de IET se encuentra en /etc/ietd.conf

Allí tendremos que configurar dos cosas principalmente:

• El nombre de nuestro target
• El nombre de usuario y la contraseña para la conexión del iniciador
• El dispositivo que ofreceremos como target

El nombre

El estándar iSCSI define que tanto los target como los iniciadores deben tener un nombre que sigue un patrón, el cual es el siguiente:

iqn.[yyyy-mm].[nombre del dominio invertido]:[identificador]

Donde:

iqn es un término fijo y debe figurar al principio.

yyyy-mm es la fecha de alta del dominio de la organización para la que estamos configurando el target

A continuación debe figurar el nombre del dominio invertido

Luego de los “:”, un identificador que podemos ponerlo a nuestro gusto, y que puede en muchos casos brindar información del target.

Un ejemplo válido sería:

iqn.2005-02.au.com.empresa:san.200G.samba

Como vemos el identificador aunque es variable y personalizable, puede reflejar el nombre dado al target, la capacidad y el servicio donde lo usaremos.

En /etc/ietd.conf definimos el nombre de nuestro target

Target iqn.2005-02.au.com.empresa:san.200G.samba

Si queremos que nuestro target requiera autenticación., podemos definir un usuario y una contraseña para que solo se conecten los iniciadores que nosotros queremos.

IncomingUser usuario-iniciador clave-iniciador

Luego debemos definir qué dispositivo ofreceremos como target. Debemos poner una línea como la siguiente:

Lun 0 Path=/dev/sda3,Type=fileio

En este ejemplo el primer dispositivo que estamos ofreciendo es la partición /dev/sda3 del servidor. La documentación nos dice que además de particiones podemos usar discos enteros, volúmenes LVM y RAID, e incluso archivos. En cualquier caso solo hay que definir el path.

El archivo contiene muchos parámetros más de configuración, que en la mayoría de los casos tienen que ver con la performance del servidor. En nuestro ejemplo, configurando estos tres parámetros nos basta.

Una vez que hemos configurado el servidor y que tenemos lista nuestra partición o disco a ofrecer, debemos levantar el servidor.

# /etc/init.d/iSCSI-target start

Con lo cual se cargará el módulo iSCSI target en el kernel y se levantará el servidor ietd que es el que gestionará las peticiones de los iniciadores.

Por último si queremos que nuestro servicio iSCSI target inicie junto con el servidor, debemos agregarlo al inicio del sistema.

# update-rc.d iSCSI-target defaults

Ya tenemos nuestro servidor iSCSI instalado y listo para servir discos a nuestra red. Ahora necesitamos un iniciador iSCSI para que se conecte a nuestro target y podamos empezar a usar los discos por la red. No preocuparse porque ese es el tema del próximo post.

Links sobre este tema:

• iSCSI Enterprise Target
• Ardis iSCSI Target (Proyecto sobre el que está basado IETD)
• Guía para instalar un target iSCSI en Linux
• Paquetes no oficiales de IET para Debian Gracias a Federico Lazcano!

¿Qué es iSCSI?

iSCSI es un extensión de SCSI, que no es otra cosa que un protocolo para comunicación de dispositivos. SCSI suele usarse en dispositivos conectados físicamente a un host o servidor, tales como discos duros, lectoras de cds o dispositivos de cinta. En iSCSI, los comandos SCSI que manejan el dispositivo, se envían a través de la red. De forma que en vez de tener un disco SCSI conectado físicamente a nuestro equipo, lo conectamos por medio de la red.

¿Pero eso no existía ya con Samba o NFS? No, esos sistemas trabajan importando un sistema de archivos mediante la red. iSCSI importa todo el dispositivo hardware por la red, de manera que en el cliente es detectado como un dispositivo SCSI más. Todo esto se hace de forma transparente, como si el disco estuviera conectado directamente al hardware.

¿Por qué usar iSCSI?

La respuesta más simple es para centralizar el almacenamiento en disco e indpendizar la información de los servidores. Por ejemplo podríamos tener un servidor iSCSI con 1 Terabyte (1024 Gigabytes) de almacenamiento que centralizara todos los dispositivo de almacenamiento de nuestra red. Por otra parte podríamos tener nuestros servidores: de correo, ftp, web, samba, todos sin discos o particiones para datos. Los discos de datos se conectarían a través de iSCSI por la red y si alguno de nuestros servidores se cayera o hubiera que hacerles mantenimiento tendríamos la información en un disco que se podría “enchufar” por la red. De manera que si tenemos un servidor secundario, no tenemos más que conectarle el disco iSCSI y tendremos el servicio andando en muy poco tiempo.

¿Y la velocidad?

Esta es una pregunta obligada. Un requisito indispensable de un buen disco es que sea rápido. Los discos SCSI suelen entregar excelentes tasas de transferencia. Pero si SCSI se lleva sobre la red entonces la velocidad podría bajar y el rendimiento decaer gravemente. Por eso iSCSI es recomendado solo para redes conmutadas de alta velocidad como las que proveen Gigabit Ethernet. Aunque iSCSI puede funcionar incluso sobre FastEthernet, no es recomendable en el caso de que busquemos performance, ya que el acceso al disco se ralentizaría mucho.

El acceso a los datos

Comparado con NFS o Samba, el acceso a los datos en iSCSI es diferente; obviamente debido a su naturaleza. En teoría, iSCSI no soporta múltiples conexiones a la vez. Por ejemplo, dos equipos no podrían utilizar el mismo disco iSCSI para escribir en él. Eso sería como tener un disco rígido conectado a dos máquinas a la vez. Lo más probable es que surgieran inconsistencis en los datos o problemas en los accesos de lectura y escritura de la información.

Aún así, existen alternativas para que ISCSI pueda soportar múltiples usuarios. Por ejemplo, el global filesystem (GFS) de RedHat, es un filesystem especialmente diseñado para permitir concurrencia de usuarios en dispositivos que normalmente no lo permiten, como iSCSI.

La arquitectura iSCSI

Como se puede ver en el diagrama, iSCSI tiene una arquitectura tipo cliente servidor; las partes que la conforman son las siguientes:

El target iSCSI

El target iSCSI es en pocas palabras el servidor. Un target puede ofrecer uno o más recursos iSCSI por la red. En las soluciones Linux para iSCSI, no hace falta que el dispositivo a exportar sea necesariamente un disco SCSI; medios de almacenamiento de distinta naturaleza se pueden usar, como por ejemplo:

• Particiones RAID
• Particiones LVM
• Discos enteros
• Particiones comunes
• Archivos
• Dispositivos de CD, cintas, etc.

El iniciador iSCSI

El iniciador es el cliente de iSCSI. Generalmente el iniciador consta de dos partes: los módulos o drivers que proveen soporte para que el sistema operativo pueda reconocer discos de tipo iSCSI y un programa que gestiona las conexiones a dichos discos.

Existen iniciadores para una amplia variedad de sistemas operativos. En Linux hay varias opciones y las últimas versiones de Windows incluso vienen con un iniciador instalado por defecto. Demás está decir que iSCSI es independiente del sistema operativo. Podemos tener un target montado en Linux y utilizar los discos en dicho target en un sistema Windows, MacOSX o incluso Solaris.

Ahora que hemos aclarado un poco el tema de iSCSI podemos centrarnos en la instalción de un servidor o target iSCSI con su correspondiente iniciador. Ese será el tema de un post futuro.

Links sobre este tema:

Artículo en la Wikipedia sobre iSCSI

RFC sobre la especificación iSCSI

Como tengo un amigo que es fan de Windows, y ahora que salió Vista está encantado con los efectos, me puse a jugar con lo que encontraba para hacer más bonito mi Debian Lenny. Había leído de lowfat, esa aplicación que te muestra tus fotos como si estuvieran desparramadas sobre un escritorio, donde las puedes apliar, girar y ordenar de una forma bastante realista. Creía que solo iba a funcionar en Ubuntu (porque al parecer todo lo “cool”, “fancy” funciona primero en Ubuntu). De hecho algunos pasos de la instalación los vi en Ubuntu Life. Pero estaba equivocado, solo fue cuestión de compilar algunas cosas y todo anduvo.

Aquí van los pasos necesarios para hacerlo andar:

Primero que nada hay que descargar los fuentes de lowfat que está en un repositorio git. Por lo tanto si no tenemos git, lo tendremos que instalar.

#apt-get install git-core

Una vez que tenemos git nos traemos los fuentes

#git clone git://people.freedesktop.org/~macslow/lowfat

#cd lowfat
El INSTALL nos dice que basta con hacer: ./autogen.sh ./configure y ./make
Pero como siempre en el transcurso saltan algunas librerías faltantes. Estas fueron las que pidió lowfat en una instalación limpiecita de lenny solo con gnome andando:

• g++
• libsdl-dev
• libsdl-image-dev

# apt-get install libsdl1.2-dev libsdl-image1.2-dev g++

Quizás haga falta correr ldconfig para que el sistema reconozca las nuevas librerías

#./autogen.sh
#./configure
#make

y listo…

El ejecutable se encuentra dentro de el directorio src. Es un único ejecutable que podemos correr desde la consola. Si queremos cambiarlo a otra ubicación entonces tendremos que copiarlo y darle permisos de ejecución al usuario que tenga la sesión gráfica corriendo. Como último detalle hay que copiar el directorio pixmaps al directorio donde copiemos el ejecutable, de lo contrario lowfat dará un error y no iniciará.

Además, agregar que al parecer lowfat no se lleva bien con compiz-fusion, porque cuando lo inicié con compiz ejecutándose no funcionaba bien.

La única documentación de lowfat nos dice como manejarlo:


F1 - normal mode (modo normal)
F2 - chaos mode (modo caos)
F3 - simple mode (modo simple)
a - sort by aspect (ordenar según el aspecto; adivina si la foto está tomada vertical u horizontalmente y la alínea)
s - sort by size (ordenar por tamaño)
d - sort by date (ordenar por fecha)
Space - pile (apila todas la fotos seleccionadas)
q, esc - quit (sale de lowfat)
i - toggle info (muestra información de la foto seleccionada)
o - original size (muestra la foto seleccionada en el tamaño original)
l - load files (abre un cuadro de diálogo para cargar las fotos)
del - get rid of file (elimina del escritorio la foto seleccionada)
r - reset position/movement (resetea la posición de la foto)
(shift) up/right - rotate right (in larger steps) (rota la foto con el teclado hacia la derecha)
(shift) down/left - rotate left (in larger steps) (rota la foto con el teclado hacia la izquierda)

mouse:
what you would expect from mouse-controls
left double-click, if you feel lost

Con el mouse desde luego podemos mover las fotos. Tanto con la rueda así como con el click izquierdo podemos acercar o alejar las fotos. Haciendo click izquierdo sobre la foto y luego doble click (derecho) traemos la foto seleccionada al frente.

Un video para que vean como me voy a regodear enfrente de mi amigo con las nuevas capacidades gráficas de Linux.