SAMBA: Linux y Windows en Red
8 June 2007
Con el crecimiento de las redes caseras y, sobre todo, con la explosión del Wi-Fi, la cantidad de equipos interconectados en los hogares crece exponencialmente. Más temprano que tarde necesitaremos compartir recursos entre equipos con los S.O. de Microsoft y aquellos potenciados por el Kernel del pingüino. Aquí te mostramos una de las formas de hacerlo utilizando SAMBA, un robusto y probado producto elaborado por la comunidad del software libre, viejo conocido de los administradores de redes corporativas.
En estos días, la interoperabilidad entre Linux y Windows es un tema de moda debido al acuerdo que, al respecto, anudaron Microsoft y Novell (dueña de SUSE Linux) y a las olas de quejas y la alarma que dicho acuerdo causó en la comunidad del Software Libre. Ocurre que esta última lo percibió como una jugada a dos puntas por parte de la empresa de Bill: por un lado, birlarse una parte de la torta que ahora se comen las pocas empresas que tienen un negocio importante montado en torno a tecnologías de Software Libre, como la propia Novell o Red Hat. Y por otro, intentar contaminar la plataforma con su propio código propietario, para, más tarde, amenazar con juicios por violación de propiedad intelectual a quienes usen este código “contaminado”, excluyendo a los clientes de Microsoft, por supuesto. Dicha estrategia, conocida internamente en Redmond como “E+E+E” (siglas de “embrace, extend, extinguish”), es característica de MS, que la ha utilizado múltiples veces para deshacerse de molestos competidores. Lo paradójico del asunto es que uno de los soft en los que se basa esta interoperabilidad entre ambos S.O. está disponible desde hace muchos años, más precisamente desde principios de 1992, cuando Andrew Tridgell se armó de un packet sniffer e infinitas dosis de paciencia para desarrollar SAMBA utilizando la técnica de “Ingeniería Inversa”, a partir de los protocolos de red diseñados originalmente por DEC y luego modificados por IBM y Microsoft.
NACE SAMBA: CÓMO Y POR QUÉ
El motivo del nacimiento de SAMBA es común al de tantos otros desarrollos de software: un programador se encuentra con una necesidad que ningún soft satisface plenamente, y decide sencillamente escribir él mismo un programa que cubra su necesidad. Andrew Tridgell, nativo de la tierra de los kiwis y los canguros, necesitaba acceder al disco de un servidor UNIX de su Universidad desde una PC con DOS. Utilizar NFS (una solución de software para esa problemática ya existente en ese entonces) en su caso no servía, ya que debía utilizar una aplicación que dependía de NetBIOS, una API propietaria de acceso a redes, desarrollada originalmente por IBM y tomada como base por Microsoft para sus productos de networking. Así que Andrew escribió primero un analizador de paquetes, que le permitió hacer un estudio exhaustivo de los paquetes de red y su contenido, con lo cual poco a poco el complejo juego de reglas que da vida a todo protocolo se fue revelando lentamente ante sus ojos. Algo bastante parecido, según las propias palabras de su creador, a intentar aprender a hablar francés simplemente sentándose en un café parisino durante horas, con todos los sentidos atentos a captar y analizar todo cuanto se dice y sucede a nuestro alrededor. Al respecto el propio Tridgell ha escrito un texto muy interesante, cuya lectura recomiendo a todos aquellos interesados en los procesos de ingeniería inversa, y que pueden encontrar aquí (lamentablemente restringido para quienes puedan leer el inglés).
QUÉ OFRECE SAMBA HOY
Como imaginarán, luego de prácticamente 15 años de desarrollo, y siendo un producto tan popular como lo es actualmente, además de su solidez y estabilidad, SAMBA nos ofrece múltiples posibilidades:
- Acceso a recursos de red (servidores de archivos, impresoras, etc.)
- Autenticación y Control de Accesos
- Resolución de Nombres
- Publicación de Servicios
Como vemos, es tan completo que hasta permite que un equipo con Linux… ¡sea Controlador de Dominio de una red Windows! Por supuesto también funciona como un simple miembro del Dominio, ya sea de una red estilo NT o de una basada en Active Directory. Sin embargo, para un uso hogareño en general, es conveniente prescindir del Dominio y utilizar una red del tipo “Grupo de Trabajo”, mucho más sencilla y, por lo tanto, más adecuada para este fin; por lo cual en la presente nota veremos cómo trabajar con SAMBA en este tipo de redes.
En este diagrama se muestra una red típica armada alrededor de SAMBA. Se destaca el uso de una utilidad de terceros basada en Web para manejar todo, evitando la tediosa tarea de editar a mano los archivos de configuración. Clickeando la imagen se la puede ver ampliada.
 |
A METER MANO
En nuestro ejemplo vamos a ver un escenario típico para una red hogareña, en donde nos valdremos de SAMBA para facilitar bastante la existencia del siempre sufrido administrador de red (¡en este caso es fundamental, ya que seremos nosotros mismos!). Contamos con un viejo, pero querido, Pentium MMX 166 Mhz, con 64 MB de RAM, que tantas alegrías nos dió en su momento, y que todavía funciona igual de bien que el primer día. Esta veterana PC, equipada con dos placas de red y GNU/Linux instalado, se convierte en un poderoso router, que hace las veces tanto de Gateway, para darle Internet al resto de nuestra red, como de Firewall, para protegernos de posibles ataques desde el exterior. Luego, tenemos una o más estaciones de trabajo (y por qué no algún Media Center, para quienes posean bastante plata en el bolsillo para gastar en tecnología) que pueden correr tanto Windows como GNU/Linux. Nuestro objetivo: acceder libremente desde cualquiera de las máquinas de la red a los recursos compartidos de las otras, así como a la impresora, conectada indistintamente (gracias a la ubicuidad del USB) a alguna de las estaciones de trabajo.
En principio, privilegiaremos la sencillez sobre la seguridad en la configuración de nuestra red. Al no existir un controlador de dominio, estaremos limitados en cuanto a la funcionalidad de autenticación y autorización. Pero podemos estar tranquilos, ya que nuestro Gateway cuenta con dos placas de red, conformando, de este modo, dos redes no comunicadas entre sí: una, entre nuestro proveedor de Internet y el Gateway, y otra, entre el Gateway y nuestra red hogareña. Sólo se rutearán desde la primera hacia la segunda aquellos paquetes que permitamos en las reglas de nuestro Firewall, y si todo está correctamente configurado, podemos prescindir absolutamente de la seguridad en nuestra red hogareña, dado que, de todas formas, los datos de las estaciones de trabajo estarán a salvo de ataques del exterior. De lo contrario, la configuración de los permisos de acceso a los recursos compartidos, en modalidad “grupo de trabajo” se vuelve engorrosa, ya que al no estar presente un Domain Controller para autenticar y autorizar, se debe recurrir a triquiñuelas como crear usuarios con el mismo nombre y contraseña en todas las estaciones de trabajo. Por lo tanto, en nuestro ejemplo, permitiremos el acceso total a los recursos compartidos, dejando para notas posteriores configuraciones más complejas que incluyan distintos niveles de seguridad.
Lo primero es instalar SAMBA en todas las PC con GNU/Linux. Los usuarios de Debian (o las distros basadas en ella) saben que una de las cosas lindas que tiene es que esto se logra en segundos, con sólo escribir apt-get install samba en la consola. Como siempre, a las preguntas que nos realice el instalador responderemos eligiendo la opción por defecto.
Antes de modificar la configuración del SAMBA, debemos realizar algunas tareas previas. Al respecto es bueno recordar que al margen de los permisos “de red” que otorguemos a los recursos compartidos declarados en SAMBA, los filesystem usados en Linux tienen sus propios permisos, y si, por ejemplo, deseamos escribir en un recurso compartido por SAMBA, el usuario remoto que estemos utilizando debe tener permisos de escritura sobre el directorio respectivo en el filesystem. Para ello crearemos un grupo y un usuario genéricos en el Linux, que serán usados por SAMBA a nuestro pedido. Siguiendo la tradición UNIXera, elegimos el grupo “nogroup” y el usuario “nobody”, aunque, por supuesto, pueden usar los que quieran, siempre y cuando ajusten correspondientemente la configuración de SAMBA.
Primero, chequeamos si existe el grupo “nogroup”:
Si el grupo ya estaba creado, grep lo mostrará, de lo contrario, no devolverá nada. En ese caso creamos el grupo:
Hacemos lo propio con el usuario, verificando si existe con id:
Si id responde que el usuario no existe, procedemos a su creación, pero omitiendo la creación de un directorio home para el usuario, ya que no será utilizado por ningún usuario “real”:
Ahora sí, llegó el momento de abrir el editor de texto favorito de cada uno y modificar la configuración del SAMBA. Como buen Debianero, yo estoy acostumbrado al NANO:
Vamos a encontrarnos con un *gran* archivo de configuración, que supera las 300 líneas, pero a no asustarse, ya que muchas de estas líneas contienen ayudas e indicaciones acerca de las distintas opciones de configuración. No es mala idea, antes de cada modificación, hacer una copia de resguardo de este archivo. Un error en la sintaxis del mismo impedirá que se levante el servicio y SAMBA no funcionará.
Antes que nada, vamos derechito a la sección “Global Settings” y configuramos los siguientes valores:
Acá pueden poner el que deseen, con la salvedad de que deberá ser el mismo en todas las máquinas. Por lo general, por defecto se utiliza GRUPO_TRABAJO. Un poco más abajo está la configuración de “Networking”. Aquí deberemos hacer una modificación MUY importante si la máquina que estamos configurando es el Gateway, ya que si omitimos este paso, expondremos nuestros recursos compartidos a toda la Internet (!). Como ya mencionamos, el gw tiene dos placas de red: una (en nuestro caso eth0) que la conecta con el ISP, y otra con el resto de la red hogareña (eth1). Así que, en este caso, nos aseguraremos de que quede comentada (con “;”) la línea que activa la interfaz eth0 en la configuración de SAMBA, y que la que corresponde a eth1 quede correctamente configurada. En nuestro ejemplo quedó así:
interfaces = 192.168.10.0/8 eth1
Para cada placa, además del nombre de la interfaz (ethX), deben configurar correctamente el segmento de red y la máscara en forma acorde a la red correspondiente (si la IP de la PC se asigna en forma dinámica, dejamos 127.0.0.0/8). Para las estaciones de trabajo, en las que, por lo común, contamos con una sola NIC (eth0), no hay margen de duda, ya que se configura la única interfaz existente.
Luego, nos dirigimos a la parte de “Authentication”, donde indicaremos a SAMBA que la seguridad se manejará a nivel de recurso, y no de usuario:
Al final de la sección de autenticación agregaremos varias líneas. Con la primera de ellas indicaremos el usuario que SAMBA usará como “guest” (es decir, el utilizado cuando se conecte un usuario remoto que no posee una cuenta local con la que ser autenticado):
Recuerden configurar esta opción en forma acorde si han creado el usuario con otro nombre. Luego, agregamos las siguientes líneas a continuación:
guest only = no
read only = no
Si desean evitar que se pueda escribir en los recursos compartidos por SAMBA, deberán poner en “yes” el valor de la propiedad “read only”. Este valor, que es general para todos los recursos, sólo se tiene en cuenta, en cada caso, si no se ha declarado de manera explícita a nivel de recurso.
Pero, justamente, pasemos a la configuración de los recursos compartidos. En este caso, y como ejemplo, crearemos un único recurso habilitado para acceso total de lectura y escritura en el directorio /shared del filesystem. Vamos a la sección “Share Definitions” del archivo de configuración y, debajo de todos los recursos de ejemplo que vienen en el archivo (algunos de los cuales son muy útiles, como, por ejemplo, el del CD-ROM y los de impresión), declaramos nuestro recurso agregando las siguientes líneas:
path = /shared
browseable = yes
public = yes
writeable = yes
read only = no
guest ok = yes
guest only = no
Como ven, las propiedades del recurso son bastante autoexplicativas y, aunque parezca redundante declarar “writeable = yes” y “read only = no” al mismo tiempo, les aconsejo hacerlo de todas formas y se evitarán más de un dolor de cabeza.
Antes de poder probar si quedó todo bien, debemos reiniciar el SAMBA para que tome los cambios en el archivo de configuración. En Debian lo logramos con este comando:
Ahora, desde la estación de trabajo que corre Win XP, simplemente ingresamos en la barra de direcciones del explorador de Windows:
Y, luego de algunos segundos (al no haber un controlador de dominio, se envía un request a TODOS los equipos de la red, lo cual demora un poco las cosas), tendremos una ventana de explorador situada en el recurso creado. Verificamos que hemos hecho las cosas bien mediante la copia de cualquier archivo a nuestro recurso, y, si funciona correctamente, ya podemos dar las primeras hurras. Si vamos a usar en forma intensiva el recurso desde esta estación de trabajo, es buena idea mapearlo como una unidad, lo cual es posible yendo en el explorador al menú Herramientas\Conectar a Unidad de red, seleccionando la unidad a la que se quiere mapear el recurso, e ingresando la dirección del mismo como lo hicimos antes. Es mejor elegir una letra alta, alejada de las unidades de discos locales como C, D, etc. Una elección popular entre los administradores de redes es la unidad R.
SAMBA COMO CLIENTE
Para acceder desde una de las máquinas con Linux a recursos compartidos en otras máquinas, disponemos de varias alternativas. La más cómoda es utilizando el navegador Nautilus (que viene con el Gnome), en cuyo caso es casi igual que en Windows, ya que basta escribir en la barra de direcciones:
También se puede montar el recurso en un directorio, mediante el comando smbmount:
Y, luego, desmontamos con smbumount al finalizar la utilización del recurso. Si queremos realizar los mounts en forma automática al bootear, se puede hacer agregándolos a /etc/fstab:
#…
//nombre_o_ip/recurso /mnt/recurso smbfs defaults 0 0
#…
Para navegar por los recursos de un equipo remoto desde la consola, tenemos el comando smbclient:
… Y A SEGUIR INVESTIGANDO
Como podemos apreciar, las posibilidades son tantas como la imaginación lo permita, y por cierto, que queda mucho por ver sobre el tema. Por ejemplo, cómo configurar SAMBA para utilizarlo como controlador de dominio, ideal para una pequeña o mediana empresa. En próximos números esperamos poder desarrollar este tema. De todas maneras, esperamos haberles brindado los fundamentos necesarios como para que puedan proseguir por sí mismos, ya que nunca debemos olvidar que “la práctica hace al maestro”. Hasta la próxima, y ¡sigan hackeando!
En esta foto, tomada hace ya cinco años, vemos al equipo de desarrollo de SAMBA en ese entonces. Ahora entendemos de dónde salieron las 500.000 líneas de código que tiene actualmente :))
 |
Hace rato que tenía ganas de postear algo sobre esta temática, ya que son cada vez más quienes no se resignan a las limitaciones de Windows, o a las complejidades de Linux, y prefieren acudir a lo mejor de ambos mundos. Y, con frecuencia, es necesario que ambos S.O. compartan recursos. Sin embargo, los post sobre Virtualización publicados anteriormente fueron los que impulsaron definitivamente este tema, ya que varios lectores nos escribieron pidiendo que tratáramos el tema de las “redes virtuales” entre VMs, o entre VMs y Anfitrión. Al respecto sólo cabe decir que, también en este caso, SAMBA es una solución ideal para compartir recursos entre VMs con distintos S.O., y todo lo explicado aquí se aplica absolutamente y sin modificaciones a cualquier máquina que pueda correr SAMBA, ya sea virtual o física.
Aclaración: Este post fue publicado originalmente en la revista POWERUSR #41. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.
Virtualización 2: CoLinux bajo Windows
8 March 2007
En el post anterior explicamos en qué consiste esta tecnología, y vimos cómo un software puede emular el hardware completo de la PC, permitiéndonos ejecutar distintos SO en el mismo equipo simultáneamente. Las ventajas que esto ofrece tienen un costo: los recursos del equipo se utilizan en forma intensiva. Pero si lo que necesitamos es ejecutar Linux bajo Windows, existe una interesante alternativa: CoLinux es un Kernel Linux que se ejecuta como un proceso más, sin emular el hardware.
Cooperative Linux (conocido como CoLinux), en lugar de emular hardware, comparte los recursos que ya existen en el SO anfitrión. Otros software de virtualización, como VMWare o Xen, ejecutan sus máquinas virtuales en el “espacio de usuario”, mientras que CoLinux tiene casi el mismo acceso a los recursos del equipo que el Kernel anfitrión. El Kernel Linux trabajará “en equipo” con el de Windows, logrando un rendimiento insuperable al ejecutar aplicaciones de Linux bajo los SO de Microsoft.
LA UNIÓN HACE LA FUERZA
Si bien el hard de nuestra PC no está diseñado para ser controlado por más de un Kernel (es decir, más de un SO) al mismo tiempo, esta “cooperación” entre Kernels se logra con una serie de drivers especiales desarrollados por el equipo de CoLinux, que permiten al Kernel Linux acceder al hardware de forma mucho más directa y veloz que a través de una capa de emulación. Y su excelente rendimiento no es su único punto fuerte: es libre y de código abierto, y tiene detrás una importante comunidad de desarrolladores y usuarios que le dan soporte y ayudan a mejorarlo versión tras versión. En concordancia con la tendencia principal de la mayoría de las distribuciones Linux, actualmente el Kernel de CoLinux es un derivado de la rama 2.6.x que permite ejecutar diversas distribuciones Linux sobre Windows. Algunas distribuciones se llevan especialmente bien con el CoLinux, como Debian, su descendiente Knoppix, o Gentoo, ideal para quienes requieran niveles extremos de optimización en la ejecución de binarios Linux. También se puede “convertir” cualquier distribución que tengamos instalada a CoLinux, con ayuda de las instrucciones que podemos encontrar en la wiki de la comunidad: http://wiki.colinux.org/wiki/Main_Page
INSTALANDO COLINUX
CoLinux, como muchos otros desarrollos de código abierto, se encuentra “hosteado” en el popular sitio de proyectos open source SourceForge.net, que provee de distintos servicios a la comunidad de desarrolladores OSS: hosting de fuentes y ejecutables, control de versiones, administración de documentación, etc. SourceForge además cuenta con numerosos mirrors en distintos lugares del mundo para facilitar las descargas. En nuestro caso, nos conviene utilizar el mirror de Brasil por ser el más cercano geográficamente. Procedemos, entonces, a descargar CoLinux desde aquí.
Una de las ventajas de CoLinux se pone de manifiesto ya desde el principio: el instalador pesa menos de 5 MB. Al ejecutarlo, luego de preguntarnos en qué carpeta deseamos instalar (aconsejamos utilizar C:\CoLinux, ya que es la que viene por defecto en los archivos de configuración) se instalará el Kernel CoLinux, los archivos de configuración y herramientas necesarias para ejecutarlo y los drivers para las redes virtuales. Finalmente, nos permitirá descargar una imagen del sistema de archivos raíz (root filesystem), indispensable para que el Kernel Linux pueda correr. En este caso aconsejamos utilizar la imagen del root filesystem Debian, que también nos guarda una pequeña sorpresa, ya que descargaremos apenas 28 MB; sin embargo, al descomprimirla, será creado un archivo de ¡1 GB! que contendrá un filesystem con una distribución Debian básica. Es importante destacar que, a diferencia de los discos virtuales utilizados por la tecnología VMWare, los de CoLinux ocupan todo el espacio máximo que se les asigna desde el principio, pero tienen una ventaja sobre estos: la herramienta necesaria para crearlos ya viene con el propio Windows: fsutil (más información en http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/fsutil.mspx).
EDITANDO LA CONFIGURACIÓN
Una vez descargada la imagen del root filesystem, la descomprimimos en la misma carpeta donde instalamos CoLinux. La imagen viene comprimida con el bzip2 (podemos descargar la versión para Windows desde [http://gnuwin32.sourceforge.net/packages/bzip2.htm]) aunque si contamos con el 7-zip o el WinRAR, también podemos utilizarlos para extraer la imagen. Luego, debemos editar el archivo de configuración de CoLinux, que reside en la carpeta que hayamos seleccionado para instalar. Dicho archivo se llama default.colinux.xml y, como su extensión lo indica, es un archivo de formato XML, por lo cual aconsejamos utilizar algún editor preparado para trabajar con este tipo de formato, por ejemplo, el excelente Notepad++, que se puede descargar en [http://notepad-plus.sourceforge.net/es/site.htm]. Por supuesto que podemos utilizar un editor tradicional como el bloc de notas si así lo deseamos, pero no dispondremos de ventajas como colorizado de la sintaxis o demarcación de la estructura del XML.
Si bien el formato del archivo de configuración difiere sustancialmente del formato utilizado por VMWare que hemos visto en la nota anterior, podemos observar que los ítems a configurar son similares: cantidad de memoria física asignada a CoLinux, configuración de los dispositivos virtuales de almacenamiento y de interfaz de red, etc. Además, el archivo viene acompañado de comentarios (en inglés) que proporcionan una valiosa ayuda sobre el uso y características de cada uno de los parámetros de configuración. En este caso, si hemos instalado en la carpeta recomendada (C:\CoLinux), el único cambio que debemos realizar antes de poder arrancar el Kernel CoLinux es indicar la ruta a nuestra imagen de root filesystem, editando el elemento siguiente:
En dicha línea reemplazaremos “c:\coLinux\root_fs” con la ruta completa a nuestra imagen root. En nuestro caso, quedó así:
Por supuesto, otra posibilidad es, en lugar de modificar el archivo de configuración, renombrar el archivo de imagen a “root_fs”.
La única otra opción que modificaremos inicialmente se encuentra en la configuración de la red virtual. En la siguiente línea reemplazamos la palabra “tap” que viene en la configuración default por “slirp” y debe quedar así:
MODALIDAD DE EJECUCIÓN
Cumplidos estos pasos, ya estamos en condiciones de arrancar el Kernel CoLinux, pero antes debemos tomar una última decisión: si vamos a ejecutar el Kernel en forma “stand alone” o como servicio de Windows. La primera opción será más recomendable cuando sólo necesitemos ejecutar aplicaciones Linux en forma ocasional, mientras que ejecutar como servicio será una opción más adecuada si hacemos uso intensivo del mismo, pudiendo incluso configurar el servicio para que se inicie solo al bootear el Windows. Otra diferencia destacable es que la ejecución en modo “stand alone” requiere tener siempre abierta una “consola” virtual (utilizaremos para ello una ventana en modo texto, similar a la que utiliza la línea de comandos estándar de Windows), mientras que la ejecución como servicio posibilita que el Kernel CoLinux se ejecute en forma “invisible” para el usuario, pudiendo invocarse si se desea una “consola” y cerrarla al terminar su uso, sin que el servicio CoLinux deje de ejecutarse. También podemos acceder a una “consola” CoLinux conectándonos a través de telnet o ssh, como si se tratara de un equipo Linux “real” accesible vía red. Una vez que decidimos cuál es la modalidad más adecuada para nuestro caso, realizamos los pasos indicados en el cuadro 1 según nuestra elección.
PRIMEROS PASOS
Llegó el momento de ejecutar el Kernel. Al arrancarlo observaremos los clásicos mensajes de booteo de Linux, y ,a los pocos segundos, nos encontraremos con el prompt de “login”. En la versión actual de CoLinux (0.6.4) tanto el usuario como la password son “root”. Nos logueamos, y lo primero que haremos será editar la configuración de red. Para ello ejecutamos:
Hacia el final del archivo observamos las siguientes líneas:
address 192.168.0.40
netmask 255.255.255.0
gateway 192.168.0.1
Debemos reemplazarlas por la siguiente:
Salimos grabando, y hacemos shutdown de la sesión CoLinux con el siguiente comando:
ACTUALIZANDO LA IMAGEN DEBIAN
Arrancamos nuevamente el CoLinux y comprobamos que la red está funcionando:
Si todo marcha bien, actualizamos la lista de paquetes desde los repositorios de Debian:
Al actualizar, el repositorio de Backports da un error, pero no lo vamos a utilizar, así que lo ignoramos. Finalmente, actualizamos Debian a la última versión:
Para quienes no estén familiarizados con Debian o sus distribuciones “herederas” como Knoppix o Ubuntu, este comando actualizará todos los paquetes presentes en el sistema a su última versión, descargando e instalando todo en forma automática. Durante este paso se nos harán algunas preguntas respecto a la configuración del sistema: simplemente responderemos, en cada caso, la opción que se nos presenta por defecto.
INSTALANDO APLICACIONES
Una vez terminado el proceso de actualización, podemos comenzar a instalar aplicaciones. Si necesitamos ejecutar en CoLinux solamente servidores (apache, mysql) podemos quedarnos con la interfaz de consola, ya que se interactuará poco con el CoLinux, simplemente utilizaremos los servicios deseados conectando a ellos desde aplicaciones Windows (como por ejemplo una IDE o un soft de diseño de sitios Web). En este caso, convendrá correr CoLinux como servicio y acceder a consola por ssh utilizando un cliente como el PuTTY, el cual (bromas sobre el nombre aparte) podremos descargar desde http://www.putty.nl/download.html
Antes que nada, recordemos que, luego de cada actualización o instalación, podemos recuperar parte del espacio utilizado borrando los paquetes de instalación:
En el caso de la imagen Debian que viene “de fábrica” esto es muy importante, ya que, de lo contrario, en sólo 1 Gb tendremos problemas para instalar varios servidores y el entorno gráfico simultáneamente.
Instalemos algunos servidores útiles:
| apt-get install ssh proftpd | Servidores de SSH y FTP |
| apt-get install apache libapache-mod-php4 php4 php4-mysql mysql-common mysql-server | Servidores Web y de Base de Datos, PHP |
| apt-get install samba | Servidor SAMBA (acceso a recursos de redes Windows) |
En cambio, si queremos utilizar aplicaciones de entorno gráfico, entonces tenemos que instalar las librerías y aplicaciones de XWindows:
Noten que no instalamos ningún servidor X. Esto es porque utilizaremos al propio Windows como motor gráfico. Si tenemos instalado el Cygwin (ver Power #37), podemos utilizar el Server que nos provee Cygwin. De lo contrario, descargaremos e instalaremos el Xming, que es un Servidor X para Windows, desde [http://sourceforge.net/projects/xming]. Luego, le indicamos a CoLinux que el Servidor X se encuentra en una máquina “remota”:
export DISPLAY
Para evitar tener que correr estos dos comandos en cada sesión, podemos agregarlos al final de /etc/profile. Finalmente, invocamos a la aplicación X deseada, por ejemplo, un terminal:
Podemos dejar que el Servidor X de Windows abra una nueva ventana para cada aplicación X, y, de esta forma, el propio Windows administrará tanto las ventanas de aplicaciones Windows como las de aplicaciones X. O, si preferimos, podemos correr el Servidor X en “pantalla completa” y utilizar un administrador de ventanas de Linux. Probemos instalar un WM (Window Manager) liviano para ver su desempeño:
Luego de arrancar el Servidor X en pantalla completa (en el caso del Xming lo hacemos utilizando XLaunch), ejecutamos el administrador de ventanas:
Ya tenemos un entorno gráfico de Linux corriendo en una ventana de Windows. Ahora podemos, por ejemplo, instalar un Firefox y tener un entorno “seguro” de navegación web (sandbox), aislado de los peligros de los virus y el spyware:
Finalmente, pongámosle la frutilla al postre. Salimos de la sesión X y, desde la consola, instalamos un entorno de escritorio Linux completo con todas las de la ley, en este caso, KDE:
Una vez terminada la descarga e instalación (en este caso será bastante más larga y habrá que tener algo de paciencia) y con el Servidor X de Windows ejecutándose en pantalla completa, corremos en la consola de CoLinux:
Y si todo marcha bien, tendremos a nuestra disposición la gran cantidad de aplicaciones que ofrece KDE… ¡en una ventana de Windows!
Y LA COSA RECIÉN EMPIEZA
Como habrán podido apreciar, estamos en presencia de una herramienta muy poderosa, que presenta numerosas posibilidades y cuyo punto fuerte es su excelente performance comparada con otros productos similares. Además de ser de código abierto, gratuito y relativamente fácil de instalar y configurar, es muy importante mencionar que, detrás de CoLinux, hay una comunidad de desarrolladores y usuarios que constantemente está trabajando para mejorarlo y colaborando con los nuevos usuarios. Por ejemplo, existe una Wiki donde podremos encontrar muchísima información técnica de CoLinux, incluso tópicos muy importantes que lamentablemente escapan al alcance de esta nota: configuración del sonido para aplicaciones Linux, acceso desde CoLinux al sistema de archivos del Windows “anfitrión” y viceversa, utilización con CoLinux de distribuciones “no virtuales” ya instaladas en nuestro equipo, y mucho más. Así que ya saben: si bien en esto (aunque parezca) no hay magia, al igual que en aquel programa televisivo de nuestra juventud, el resto depende de ustedes. Feliz hacking.
Ejecución Stand Alone:
Crear un acceso directo con los siguientes valores
Destino: C:\coLinux\colinux-daemon.exe -c default.colinux.xml
Iniciar en: C:\coLinux
Ejecución como servicio:
Para instalar el servicio, ejecutar desde la línea de comandos:
C:
cd \colinux
colinux-daemon.exe -c default.colinux.xml –install-service “Cooperative Linux”
Para eliminar el servicio, ejecutar desde la línea de comandos:
C:
cd \colinux
colinux-daemon.exe –remove-service “Cooperative Linux”
Para ejecutar el servicio tanto en forma automática como manual, se lo puede hacer desde el administrador de servicios (Panel de control/Herramientas Administrativas/Servicios). También podemos iniciar el servicio en forma manual desde la línea de comandos de la siguiente manera:
net start “Cooperative Linux”
Debian GNU/Linux cuenta con una rama “estable” y otra de “pruebas”. La diferencia entre ambas es que la última incorpora las últimas versiones de los paquetes de software y las tecnologías más recientes surgidas en el mundo Linux, mientras que la primera no está tan actualizada, pero su fiabilidad es superior, haciéndola preferible para un entorno de producción.
La imagen Debian que viene con CoLinux es versión “stable”. Para actualizar a “testing”, ingresamos en la línea de comandos:
nano /etc/apt/sources.list
En este archivo veremos varias líneas similares, siendo la primera la siguiente:
deb http://ftp.us.debian.org/debian/ stable main
Comentamos con # o borramos todas las líneas menos la primera, en la cual reemplazaremos la palabra “stable” por “testing”. También podemos cambiar de repositorio si así lo deseamos; si, por ejemplo, tenemos problemas para conectarnos con el que está configurado, o deseamos cambiar por un mirror más cercano geográficamente, reemplazamos la URL del repositorio original por la que deseemos. En nuestro caso, usando un repositorio de Argentina y la versión testing el archivo sources.list quedó así:
deb http://debian.logiclinux.com/debian testing main
Además de soportar los tipos de red que explicamos en el post anterior, es decir Bridged y NAT, CoLinux cuenta, también, con la posibilidad de utilizar un tipo de conexión de red basada en un demonio llamado SLIRP. Este demonio funciona de forma similar a NAT, manteniendo una conexión privada entre CoLinux y su anfitrión, con la diferencia de que funciona en una sola vía: se puede acceder desde CoLinux a otras interfaces de red conectadas al host, pero no a la inversa. Si bien es el tipo de conexión de red virtual más lenta, también es la más sencilla de configurar y mantener, y la más adecuada para trabajar en modo “prueba de fallos”.
En esta imagen vemos un escritorio KDE corriendo bajo Windows XP. Firefox (bajo KDE) muestra la página del proyecto CoLinux. Clickeando la imagen se la puede ver ampliada.
 |
Aclaración: Este post fue publicado originalmente en la revista POWERUSR #39. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.
