.:: HeCSa blog ::.

SPICE - Una introducción para entenderlo

2012-01-24T23:24:00.002-03:00

(Artículo publicado en la revista Tuxinfo: http://www.tuxinfo.com.ar )

    Ya hemos hablado, en varias oportunidades, sobre formas de virtualizar servidores. También hemos abordado los temas relativos a la virtualización de escritorios. Alguna vez hablamos de computación en la nube, y nos maravillamos por la forma en la que este concepto evoluciona y se aplica, cada día, a más elementos que hasta ahora acostumbrábamos usar en forma local. Y es en este tópico en particular donde nace una nueva forma de exportar las interfaces gráficas de los escritorios para alimentar clientes delgados, o PCs que ya no tienen la potencia necesaria para funcionar por sí solas. SPICE, un acrónimo de “Simple Protocol for Independent Computing Environment”, será el invitado de honor de este artículo.

    Hoy nos pondremos a analizar SPICE, que está emergiendo como una tecnología alternativa, pero altamente mejorada, a los sistemas de escritorios exportados por la red, y que se perfila para ser, en un futuro cercano, el protocolo elegido cuando se deseen las mejores prestaciones en lo que a integración, velocidad y gestión de audio y video refiere.

Dos se vuelven uno

    SPICE fue originalmente desarrollado por la empresa Qumranet, quien en su época de independencia corporativa se dedicaba a desarrollar entornos de virtualización de escritorios basados en el uso de KVM (Kernel Virtual Machine). Suena bastante lógico que esta empresa haya trabajado sobre este protocolo si tenemos en cuenta que fueron ellos mismos los que crearon y mantuvieron el mismísimo hipervisor KVM, que hoy en día podemos ver en sistemas operativos GNU/Linux y hasta en OpenIndiana gracias a los aportes y el desarrollo de la empresa Joyent.

    Este producto resultó como un subconjunto de su idea original, Solid ICE, que en su momento parecía estar posicionándose como el producto de virtualización de escritorios por excelencia, dado que entregaba sus interfaces mediante el uso de una interfaz web, o un pequeño cliente delgado. Como todos nos podemos imaginar, ICE es parte del nombre SPICE, justamente por ser el acrónimo de “Independent Computing Environment”.

    Y como muchas veces pasa en el mundo corporativo, esta pequeña empresa israelí que armaba soluciones de código cerrado para GNU/Linux fue comprada en el año 2008 por Red Hat, quien un tiempo después integró su cartera de productos con los que Qumranet poseía. Por supuesto, abrió su código a las comunidades, permitiéndoles alimentarlo y acrecentarlo para llegar a ser lo que es ahora.

Lo que pensamos que es

    Así es que SPICE es una solución de computación remota que provee a sus clientes acceso a sus entornos gráficos y dispositivos (teclado, mouse, micrófono, parlantes, etc.). Logra una experiencia similar a la que se tiene cuando se interactúa con una máquina local gracias al uso de un sistema de análisis de potencia que dependiendo de lo que se posea del lado del cliente puede bien enviar comandos para generar (render) los gráficos del lado del cliente, si éste tiene suficiente potencia, o puede procesar y sólo enviar los elementos necesarios para dibujar pantallas del lado del cliente, si el cliente tiene poco poder de procesamiento.

    A diferencia de los protocolos de presentación remota de escritorios, tales como RDP, VNC o ICA, SPICE se presenta como una arquitectura basada en varias capas que interactúan para mejorar la experiencia del usuario. Estas capas son:

SPICE Driver: Es un componente que se encuentra en cada escritorio virtual. Un escritorio virtual es una de las máquinas virtuales que se podrá generar partiendo de un hipervisor como lo es, efectivamente, KVM.
SPICE Device: Es éste el componente existente en el entorno de virtualización en sí mismo, como ser un hipervisor.
SPICE Client: Este componente reside del otro lado de esta relación, es decir, en el cliente delgado, PC a punto de ser tirada a la basura por vieja, o el navegador. A través de esta capa se accede a cada escritorio virtual.

    Desde el punto de vista de la arquitectura, SPICE está compuesto por el protocolo SPICE, el servidor SPICE, y el cliente SPICE. Sus capas de “Driver” y “Device” serán entregadas por un dispositivo QLX y un driver QLX, respectivamente. El dispositivo QLX se encuentra en el paquete de virtulización “qemu”, y el driver QLX en el mismo sistema operativo que exporta su interfaz gráfica.

    Cuando un cliente se conecta a un servidor SPICE, lo hace a través de canales. Cada tipo de canal está dedicado a un tipo de datos en particular. Usa su propio socket, y puede estar encriptado utilizando SSL. Del lado del cliente cada canal será manejado por un hilo de procesamiento separado (thread), lo que nos permitirá definir valores que gestionen el nivel de rendimiento de nuestros escritorios. Si quisiéramos, podríamos aplicar QoS (Quality of Service) a cada thread, y entonces modificar su grado de precedencia dentro del sistema operativo.

    El canal principal se llama “RedClient” y es el responsable de controlar todos los demás. Parte de este control es la creación de canales, su conexión y desconexión, entre otros.

    Entre los demás canales encontramos:

Main: Este canal está implementado por RedClient.
DisplayChannel: Es el responsable de gestionar los comandos gráficos, así como las imágenes y los flujos de video.
InputsChannel: Es quien gestiona la entrada por teclado y mouse.
CursorChannel: Es el que maneja la posición y visibilidad del cursor.
PlaybackChannel: Para nuestra grata alegría, este canal maneja la forma en la cual el servidor envía audio y video al cliente de forma tal de permitir ver, por ejemplo, videos en forma remota con prácticamente ningún tipo de retardo.
RecordChannel: Es el encargado de capturar audio y video del lado del cliente, y enviarlo al servidor.

    A diferencia de otros protocolos que envían al cliente actualizaciones de frame-buffer, SPICE envía comandos de gráficos 2D, y hasta 3D, si bien este último aún no está listo. Media hora de horno, y lo podremos disfrutar.

Algo un poco divertido

    Veamos, entonces, la forma en la que se establece una conexión entre un cliente y un servidor de SPICE.

    El proceso de conexión de canales es iniciado por el cliente. Éste envía un mensaje (RedLinkMess) al servidor. Entonces, el servidor responde con otro mensaje (RedLinkReply). Cuando el cliente recibe el RedLinkReply examina su código de error, y actúa en consecuencia. En el caso de no haber un código de error (porque no han habido errores) encripta su contraseña utilizando la clave pública que le envió el servidor dentro del mensaje RedLinkreply y se lo envía al servidor. Entonces el servidor recibe la clave, y envía un mensaje más con el detalle del enlace que el cliente debe utilizar. El cliente examina el link, y si es adecuado (se verifica que su código de error coincida con el que el cliente posee) se establece una conexión válida. No es tan terrible, y ocurre en una fracción de segundo.

    Si alguna vez hemos viajado en un autobús (colectivo para mis paisanos) sabemos que de tanto en tanto hemos prestado nuestro boleto a un inspector que nos lo solicitaba para saber si habíamos pagado o no. Si habíamos pagado, todos felices. Si no habíamos pagado, bueno, nos bajaban del autobús, generalmente acompañados de algún vocablo o frase mundana que evocaba a un pariente cercano nuestro.

    SPICE también tiene una forma de controlar boletos (tickets) a través de su sistema de ticketing. Este sistema es la forma que tiene SPICE para asegurarse que el cliente que está sólicitando la conexión es una fuente confiable. El servidor logra esto generando un ticket que contiene una clave y un tiempo de expiración. Cuando el tiempo de la conexión supera este valor, el ticket completo expira.

    Este ticket se encontrará encriptado generando una clave RSA de 1024 bits cuya porción pública es enviada al cliente mediante el mensaje RedLinkInfo. El cliente utiliza esta clave para encriptar la contraseña y enviarla de vuelta al servidor a través del mensaje recién comentado, RedLinkMess. Entonces el servidor desencripta la contraseña, la compara con el ticket, y se asegura que se ha recibido dentro del período de tiempo establecido.

    Para hacer corta una historia larga, SPICE implementa una forma de comunicación muy parecida a la que tiene el mismísimo protocolo TCP/IP, con formatos propios de ping, por ejemplo.

Moverse

    Hasta ahora nos hemos focalizado en el caso de tener un servidor y un cliente. Pero ¿qué pasaría si un servidor se debe sacar de línea, o si sencillamente se cae, producto de un mal funcionamiento? Todo está pensado en el protocolo SPICE, y para casos como estos, tenemos a nuestra disposición un conjunto de mensajes que nos permitirán migrar la sesión desde un servidor a otro.

    Principalmente, se comenzará enviando mensajes para que se migran los canales de mensajes que el cliente se encuentra utilizando, y que por lo tanto están abiertos. El canal principal será el que utilizará para iniciar el proceso de migración de canales cuando el servidor envía un mensaje al cliente. Entonces éste examina sus componentes, y envía una respuesta al servidor.

    Entonces es que el cliente comienza a utilizar los canales de comunicación con el servidor de destino, desafectando de esta responsabilidad al servidor de origen. Así de sencillo es que una sesión pase de un servidor a otro.

    Si pensamos en un esquema de computación en la nube, donde no hay uno, sino cientos de servidores funcionando como si fueran uno solo, veremos que este mecanismo es extremadamente útil, ya que nos permite balancear la carga de las conexiones entre los diferentes servidores sabiendo que existe la posibilidad de mover sesiones desde un servidor a otro sin generar inconvenientes en el cliente, entregándole una sensación de continuidad muy buena.

    Y por supuesto, dado que uno de los usos del sistema de escritorios virtualizados es el de alimentar soluciones de recuperación ante desastres, encontramos en SPICE una excelente opción para entregar escritorios remotos aún cuando un centro de cómputos entero se destruya, pasando a otro centro de cómputos alternativo sin que el cliente note la diferencia.

Si te querés divertir

    Para finalizar este artículo sobre las bondades del sistema SPICE, abordaremos un tema que ha dejado con la boca abierta a muchas personas. Es la capacidad de manejar video y audio en forma remota prácticamente sin retardo entre el servidor y el cliente, inclusive sobre redes WAN como lo es internet.

    SPICE ofrece muchos mecanismos diferentes de compresión de imágenes que se pueden elegir en el momento de inicializar el servidor, y dinámicamente mientras éste está funcionando. Un método propietario de SPICE es el denominado Quic, basado en el algoritmo SFALIC.

    Como siempre, SFALIC es un acrónimo que significa “Simple Fast and Adaptive Lossless Image Compression”. Resulta que este algoritmo ha sido diseñado, desde su base, para entregar compresión a velocidades elevadísimas. Se basa en predicción lineal, y un método de modelado predictivo de control de errores. Por lo tanto, Quic tendrá un manejo predictivo para el envío de imágenes, permitiendo entonces entregar video por medio de redes WAN con un nivel increible de velocidad y exactitud.

    Otra opción de compresión es LZSS, o su pariente, el Global LZ (Lempel Ziv), o GLZ, que gestiona cambios en las imágenes para enviar comandos de renderización al cliente. Sin meternos en demasiados detalles, GLZ es un algoritmo que analiza las repeticiones de ocurrencias dentro de una cadena de audio, por ejemplo, y las parametriza para evitar el envío redundante de información.

    Imaginemos este último como si escucháramos una canción de discoteca, donde por media hora se escucha el mismo ritmo, las mismas meoldías y el mismo estribillo por períodos de un minuto y medio. No tendría sentido enviar por red media hora de sonidos, si se puede enviar sólo un minuto y medio, y luego un parámetro que especifique la cantidad de veces que se debe repetir. Lo mismo para el video, y así tenemos como resultado un sistema de audio y video bidireccional de alta velocidad.

Conclusión

    Hemos metido nuestra nariz en el protocolo SPICE, y nos hemos enterado que el mundo no termina donde VNC, RDP o ICA nos han dejado. Encontramos que este protocolo, que está en plena producción para entornos virtualizados de escritorios, está siendo mejorado para que se comporte y se maneje de la misma forma en la que hoy usamos VNC, por sólo citar un ejemplo de notable simplicidad.

    Esperemos ver en breve estas implementaciones funcionando en nuestros servidores. Como hacemos en estos casos, no podemos sino sacarnos el sombrero ante tan buen producto ;-) . ¡Nos vemos el mes que viene!

Sobre la originalidad y la reacción

2012-01-24T22:31:00.000-03:00

Hace ya un buen tiempo tuve este debate con alguien. Ya ni recuerdo qué lo disparó, pero recuerdo haber hablado de esto. No sé si fue alguna medida internacional de esas que nos dejan boquiabiertos, o alguna otra cosa.
La cosa es que, con todo el tema de SOPA y PIPA, otra vez hablamos de estos temas.
Cuando menos nos lo esperábamos, nuevamente apareció la amenaza de tener un Internet censurado. Y no fue sólo una amenaza, ya que algunos sitios, como es el caso de Megaupload, fueron cerrados por el gobierno de un país diferente del mío. No quiero decir con esto que las decisiones de mi gobierno siempre representan mi pensaniento...
Como nota de color, cito un diario de mi tierra que decidió hablar de Anonymous y Sony, aún luego de haber declarado, el mismo Anonymous, que en ESE caso sí no tenía nada que ver. No hay nada que hacer. El que nació para clarinete no llega a saxofón. No tiene nada que ver, pero leyendo sobre SOPA y PIPA en ese diario me encontré con eso. Me hizo reir un rato.
La cuestión es que generalmente nos encontramos ante actitudes desmesuradas por parte de algunas entidades no representativas, o al menos no para nosotros, que apuntan a defender a quien le da de comer. Ante eso, tenemos dos posibilidades. Una es demostrar que podemos también darles de comer (no, no me gusta esa opción), y la otra es reaccionar en consecuencia.
Claro está, todo tipo de reacción es eso: una respuesta a la acción original de alguien o algo.
Entonces, mi idea es bien sencilla, y se basa justamente en la originalidad. Es decir basta a todo este juego de reacciones, y comenzar a tener acciones originales, que apunten al beneficio de la comunidad informática en general, y a la libertad de que gozamos.
Entonces, eso implicaría una nueva organización que esté completamente de espaldas al esquema de control por parte de entidades como aquellas de que hemos tenido tristes noticias últimamente, manejada por personas que sí se interesen en lo que esta tecnología (léase: ideología) tiene para ofrecer.
Hay un millón de cabos sueltos en este esquema de originalidad, así que agradeceré que los que lean esto le pongan y agreguen los pensamientos que se les crucen, ya que mi cabeza está explotando de repentinas ideas viejas, pero muy renovadas.
Salutte!

Otra vez VirtualBox

2012-01-07T23:52:00.003-03:00

Como lo hago siempre luego de instalar un nuevo sistema operativo en mi máquina, me decidí a agregar el repositorio para que me funcione el YUM de mi Fedora 16 con VirtualBox, y así poder revivir mis máquinas virtuales.
Luego de la instalación del repo y de VirtualBox, en lo que no voy a ahondar porque no tendría sentido considerando que está más que claro en el mismo sitio virtualbox.org, me dispuse a instalar el tan querido Extension Pack de VirtualBox para tener RDP, USB, y algún que otro beneficio en las máquinas virtuales.
Pero la sorpresa no fue muy agradable cuando me encontré con el mensaje "Failed to install the Extension Pack The installer failed with exit code 127: The value for the SHELL variable was not found the /etc/shells file".
Más abajo menciona algo sobre que el incidente ya ha sido reportado.
Así que hurgando por la red me encontré con que en un sistema recientemente implementado se debe instalar, primero, todo el kit de compilación de kernel, y el dkms.
Allá vamos, ejecuté, como root:

# yum install dkms binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel

No fue tan terrible, sólo 28 MB de binarios debieron bajar a mi máquina. Entonces nuevamente fui a la carga haciendo doble click en el ícono correspondiente al Extension Pack. Pero nada, el mismo error de antes.

Mirando un poco el comando VBoxManage me encontré con un hermoso parámetro, justamente el "extpack". Efectivamente, era lo que estaba buscando.

No tuve más que ejecutar:

$ VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack

WARNING: The vboxdrv kernel module is not loaded. Either there is no module

available for the current kernel (3.1.6-1.fc16.x86_64) or it failed to

load. Please recompile the kernel module and install it by

sudo /etc/init.d/vboxdrv setup

You will not be able to start VMs until this problem is fixed.

0%...

Progress state: NS_ERROR_FAILURE

VBoxManage: error: Failed to install "/home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack": The installer failed with exit code 127: The value for the SHELL variable was not found the /etc/shells file

VBoxManage: error: This incident has been reported.

Bueno, otra vez lo mismo, pero esta vez en modo texto.

Lo hice sencillo, confié en la lógica de los mensajes, y por ende de los programadores de este excelente producto, y me decidí a rebootear el sistema para poder tener el módulo compilado. Pero antes, me dije a mí mismo "no será que algún programador, quizá, no es tan brillante como mi cerebro opina, y se olvidó de verificar si quien lo ejecuta es root?", e hice lo mismo como ese usuario, y no como el mío, hecsa.

El resultado fue interesante:

# VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack

WARNING: The vboxdrv kernel module is not loaded. Either there is no module

available for the current kernel (3.1.6-1.fc16.x86_64) or it failed to

load. Please recompile the kernel module and install it by

sudo /etc/init.d/vboxdrv setup

You will not be able to start VMs until this problem is fixed.

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Successfully installed "Oracle VM VirtualBox Extension Pack".

Si bien me dispuse a rebootear mi maquinilla, me puse a pensar que los programadores se equivocaron en varias cosas:

- Se olvidaron de verificar si el usuario que ejecuta esto tiene permisos de root o no.

- Dicen que no se podrá levantar ninguna VM, pero no es así, dado que sí levantan, pero sin el Extension Pack, al menos hasta que rebootee. Pero luego del reboot, la gran sorpresa: las máquinas virtuales aún no levantaban el USB.
Bien, seguí las instrucciones de ejecutar:

# /etc/init.d/vboxdrv setup

...y luego volví a probar suerte...pero sin suerte. Los USB aún no se ven, y probaré volver a bootear para ver si ahora sí los levanta.
Luego del reboot, ejecuté de nuevo:

# VBoxManage extpack install --replace /home/hecsa/Downloads/Oracle_VM_VirtualBox_Extension_Pack-4.1.8-75467.vbox-extpack

0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Successfully installed "Oracle VM VirtualBox Extension Pack".

Wow! Sin erorres! Pero nada es tan bello, el sistema sigue sin reconocer el subsistema USB.
La frustración no tiene límites...qué quieren que les diga...esto con Sun no pasaba...

[ACTUALIZACIÓN - GRACIAS SALVA!!!]
No olviden agregar Vuestro usuario al grupo vboxusers, de esa forma al reloguearse todo vuelve a estar en su lugar, y el error desaparece.

Punk Fluid, the Shorewall

2011-08-08T21:55:00.001-03:00

Para los que ya se cansaron de saber que sus máquinas están abiertas al mundo y no se animaron a jugar con las herramientas que Netfilter posee, en este artículo veremos algunos conceptos iniciales sobre la teoría de filtrado de paquetes en GNU/Linux, apuntando a una implementación del producto Shorewall para una instalación muy típica.

La problemática

El escenario planteado comienza a tomar forma cuando vemos el estado inicial de nuestra instalación, y el punto al que queremos llegar. De esa forma veremos cómo encarar un proyecto en el cual tengamos que implementar un sistema del tipo firewall, utilizando la mayor cantidad de filtros, redireccionamientos, y demás juguetes posibles. Y todo esto lo haremos implementando el producto Shorewall para simplificar nuestra dura vida.

Originalmente nuestra red sólo tiene una salida a internet, con dirección IP pública variable o fija (no modifica mucho el contenido de este artículo que esto varíe, ya que en el caso de no tener una dirección IP fija, de seguro se podrá utilizar algún servicio de DNS dinámico para los casos de IP variable, como ser dyndns, o no-ip). A través de un pequeño equipo basado en GNU/Linux con dos tarjetas de red, una que se conecta con esta salida pública, y otra apuntando a la red privada, es que todos los integrantes de nuestra empresa están obteniendo salida a Internet utilizando un proxy (léase Squid, o lo que se prefiera. En nuestro caso pensamos en Squid) configurado en el puerto 8008.

Veamos este diagrama esquemático para tener una idea más acabada de la instalación existente:

El desafío planteado incluye varios elementos a tener en cuenta, como ser:

Todo cliente que quiera salir a Internet directamente, y sin configurar su proxy en su sistema, deberá ser redirigido automáticamente al puerto 8008.
Todo protocolo de red diferente de la navegación por Internet deberá salir al mundo utilizando enmascaramiento de direcciones IP.
Sólo habrá un cliente que tendrá permitido salir a Internet sin pasar por el proxy, y tendrá la dirección IP 10.100.100.10.
La red interna continuará utilizando el rango de direcciones IP 10.100.100.0/24.
Se implementará un servidor Web interno, que no deberá ser accedido desde afuera de la red. Su dirección IP será 10.100.100.50.
Se deberá implementar un servidor de aplicaciones que utilice los datos de la base que se encuentra en un servidor con dirección IP 10.100.100.100. El servidor es PostgreSQL, por lo que se accede a sus datos a través del puerto 5432. El software del servidor de aplicaciones es un Tomcat, que usa el puerto TCP 8080 para funcionar.
La puerta de enlace predeterminada de todos los puestos clientes será 10.100.100.1, es decir, será el servidor que ahora es un proxy.

De acuerdo a estas premisas, vemos que el esquema de red original al menos a nivel físico no cambiaría demasiado. Sólo hay un punto que es fundamental y que se modificará, que es el correspondiente a dónde se pondrá el servidor de aplicaciones.

Como se pretende que dicho servidor sea visible desde el mundo exterior, y que se conecte con un servidor de bases de datos, tenemos que pensar en que si lo ubicamos dentro de la red interna, quien ingrese a él desde Internet, también estará en posición de violar las demás máquinas de la red interna. Para ello, tendremos que crear una nueva red que permitirá sólo el ingreso desde Internet a través del puerto 80, y sólo el contacto con el servidor de bases de datos a través del puerto 5432. Así es como aparece el concepto de zona desmilitariada, o DMZ.

La DMZ es una red que permitirá esta comunicación, de forma que si alguien pudiera ingresar y romper nuestro servidor de aplicacciones, no podría acceder a más que el puerto 5432 de nuestro servidor de bases de datos. Desde afuera de nuestra red, los clientes deberán apuntar a un URL normal, sin invocar el puerto 8080, por lo que de alguna forma tendré que redirigir el puerto 80 al 8080 del servidor de aplicaciones.

Por otro lado, si estamos hablando de una nueva red, tendremos que pensar, también, en un nuevo rango de direcciones IP. Necesitamos que estas direcciones sean privadas, por lo que hemos definido que las mismas se encuentren en el rango 10.100.150/0. La pata del servidor firewall tendrá la dirección 10.100.150.1, y el servidor Tomcat tendrá la dirección 10.100.150.10.

Con estos puntos en mente, entonces, el esquema de nuestra red queda modificado para tomar esta forma:

Si se quiere pasar a meter mano, no hace falta leer las secciones con la teoría de lo que implementaremos. Aún así, recomiendo dejar de lado el pragmatismo por un instante, y leerlas para comprender qué es lo que estaremos haciendo, y así poder modificar lo que se exponga en este artículo de forma acorde a nuestra instalación.

Conceptos

Netfilter es el nombre que recibe el conjunto de porciones de código que están dentro del kernel de GNU/Linux y que le permiten registrar el comportamiento de las funciones de red utilizadas por cada paquete cuando pasa por un sistema y hace uso de ellas.

Por ejemplo, si un usuario ejecuta el comando “ping” para verificar la existencia de un sistema en la red, la máquina de destino de ese comando debe tener un programa que escuche el protocolo que usa el “ping” (ICMP), y por lo tanto algunas funciones en el kernel que registren el uso de los recursos de red para esta tarea.

A través de Netfilter podré modificar el comportamiento de cada paquete de red que llegue o salga de una máquina.

Lo más común del mundo es conocer Netfilter no por su mismo nombre, sino por la implementación de programas como “iptables” en los kernels 2.4 y 2.6, por “ipchains” en los kernels 2.2, y por “ipfwadm” en los kernels 2.0.

¿Cómo es que funciona, entonces, algo como iptables, y cómo nos ayudará a realizar nuestra tarea? Sencillo, iptables conservará una serie de reglas de coincidencia que permitirán la ejecución de determinadas acciones cada vez que un paquete de red cumpla con alguna de ellas. Entonces, de seguro nos encontraremos con dos partes bien definidas en cada regla:

Una regla de coincidencia, donde podré especificar protocolo, puerto, dirección IP de origen y de destino, y conjunto de reglas a la que quiero agregarla.
Una acción o serie de acciones a ejecutar sobre los paquetes de red que coincidan con dicha regla.

Por ejemplo, para el caso que queremos implementar, algunas reglas serían:

Si un paquete de red quiere ingresar vía Internet, y apunta al puerto 80, redirigirlo al puerto 8080 del servidor 10.100.150.10 que se encuentra en la DMZ.
Si un paquete de red tiene origen en la red interna, tiene dirección IP diferente de 10.100.100.10, y quiere acceder a Internet, redirigirlo al puerto 8008.
Impedir el ingreso de cualquier paquete de red, no importa su origen, al firewall o cualquier otra red interna, a menos que no ingrese explícitamente por el puerto 80.

La lista de reglas en “pseudocódigo” siguen para representar la realidad de nuestras premisas. He escrito sólo algunas aquí, que repasaremos en el momento de realizar la implementación.

Ahora bien, iptables tiene una sintáxis que no es exáctamente amigable a la hora de generar reglas. Puede ser engorroso, algo confuso, y muchas veces un error nos lleva a tener un problema de seguridad grave. Aquí es donde el programa Shorewall hace su aparición, demostrándonos que todo se puede simplificar considerablemente cuando se quiere.

Shorewall

Shorewall, una abreviatura de “Shoreline Firewall”, como comentamos más arriba, viene a ser la herramienta que simplificará la configuración de iptables al punto de volverse casi documentada por sí misma. Lo que antes es una serie de reglas larguísima, ahora es sólo unas cuantas líneas en algunos archivos. Cuando Shorewall se ejecuta lee estas líneas de configuración, y con la ayuda de iptables genera todas las reglas necesarias para hacer lo que hemos definido. Y iptables, como vimos más arriba, hace uso de Netfilter para ello. Ahora las piezas del rompecabezas comienzan a encastrar, ¿no?.

Un punto importante a tener en cuenta es que Shorewall no es un proceso demonio que estará en ejecución todo el tiempo, sino que se ejecuta para realizar sus configuraciones, y luego finaliza, por lo que carece de sentido verificar si está o no en ejecución, y sí el verificar si las reglas que hemos configurado están activas. Para esto último, una mirada rápida al archivo /var/log/messages o /var/log/kern.log serán suficientes, así como la ejecución de “iptables -L”.

Shorewall se instala muy fácilmente. Se utilizará “apt-get” o “rpm” de esta forma:

# apt-get install shorewall

(para los sistemas operativos basados en Debian, como ser el mismo Debian o Ubuntu)

Los paquetes para Red Hat, CentOS, Fedora, Suse y demás distros basadas en .rpm se pueden bajar directamente de la página de Shorewall (http://shorewall.net), e instalar con el comando “rpm -Uvh PAQUETE.rpm”.

Una vez instalados los paquetes, encontraremos ciertos archivos y directorios nuevos, a saber:

Directorio /etc/shorewall: en él encontraremos todos los archivos de configuración de este paquete a nivel de reglas.
Archivo /etc/default/shorewall: ciertas configuraciones de caracter más general se encontrarán en este archivo, como ser la orden de ejecutar o no Shorewall cuando se invoque. Sirve para generar la configuración sabiendo que nadie va a ejecutarlo y, por error, dejarnos por ejemplo sin acceso al servidor firewall.
Archivo /etc/init.d/shorewall: este archivo estará relacionado por medio de links simbólicos con los correspondientes en los directorios /etc/rcX.d.
Archivo /var/log/kern.log: en este archivo, típicamente, se dejarán los mensajes correspondientes a las acciones que se han ejecutado a nivel de kernel cuando un paquete de red coincidió con alguna regla.

Con todo esto instalado, comenzaremos a transformar nuestras premisas en reglas reales.

Reglas y escuadras

Shorewall utiliza para su proceso de configuración una serie de alias que permiten asociar zonas de red a tarjetas o conexiones de red. Una zona de red será aquella que tenga determinada condición común, como ser “Red Interna”, “Red Externa”, “Zona Desmilitarizada”, etc.

En nuestro ejemplo, consideraremos tres zonas de red diferentes; la red interna, que será la que corresponde a todo lo que está dentro de nuestra propia red y que queremos proteger del mundo exterior; la red externa, que comprende ni más ni menos que a todo Internet; y finalmente la zona desmilitariada, que será aquella que contendrá sólo los servidores que queremos exponer parcialmente hacia la red externa, y parcialmente hacia la red interna, sin disminuir por ello el nivel de seguridad.

Sus nombres de zona serán, entonces, “lan” para la red interna, “wan” para la red externa, y “dmz” para la zona desmilitarizada.

Suponemos que nuestro equipo firewall dispone de tres tarjetas de red, denominadas:

eth0: corresponde a la red interna, o zona “lan”.
eth1: corresponde a la red externa, o zona “wan”.
eth2: corresponde a la red intermedia, o zona “dmz”.
fw: si bien no es una tarjeta de red, se podrán realizar conexiones hacia y desde él.

Debemos, entonces, asociar cada tarjeta o conexión de red a una zona dentro de los archivos de configuración de Shorewall. Para ello, editaremos o crearemos el archivo /etc/shorewall/interfaces con el siguiente contenido:

lan eth0

wan eth1

dmz eth2

Sencillo, ¿no? Ahora bien, como Shorewall soporta tanto zonas configuradas con Ipv4, como aquellas con Ipv6, procederemos a editar o crear el archivo /etc/shorewall/zones, donde definiremos cuál de las dos usaremos, o si una zona se trata del mismo firewall. En nuestro caso, será Ipv4:

fw firewall

lan ipv4

wan ipv4

dmz ipv4

El motivo por el cual se debe dar de alta el firewall dentro de las zonas es que se podrían generar reglas que se apliquen sólo cuando determinado tráfico de red es hacia o desde el firewall, y no a través de él.

Teniendo las asociaciones listas, veremos cuál es el formato que tienen dos archivos importantes: /etc/shorewall/policy y /etc/shorewall/rules.

En general, el formato será basado en columnas que definirán:

Resultado esperado: es el resultado que pretendemos cuando un paquete de red coincide con una determinada regla. Por ejemplo, podríamos especificar:
ACCEPT: el paquete de red es aceptado.
DROP: el paquete de red es descartado.
REJECT: el paquete de red es denegado. Difiere del anterior en que quien lo envía toma conocimiento de esta acción.
DNAT: Se ejerce “NAT” sobre la dirección de destino. En nuestro caso, todo lo que llegue al puerto 80 del servidor firewall, será redirigido al puerto 8080 del servidor de aplicaciones, y las respuestas de dicho servidor saldrán como si nunca hubiera habido un redireccionamiento. Por eso se llama “Destination NAT”.
SNAT: si un cliente de la red interna debe realizar un pedido a un servidor en la red externa, su dirección será reescrita de forma tal que cuando el servidor responda, dicha respuesta llegue nuevamente al cliente en cuestión. Por eso se llama “Source NAT”.
Cliente: es el punto donde se genera la comunicación de red. Por ejemplo, en el caso de una conexión desde Internet hacia nuestro equipo, la máquina que hace el llamado por medio de su navegador será el cliente.
Servidor: es el punto al cual llegarán los paquetes de red. En el caso del servidor del proxy, por ejemplo, el cliente será cualquiera de los puestos de trabajo, y el servidor estará en algún lugar de internet.
Familia de protocolos: en este caso, la familia de protocolos podrá ser “tcp”, “udp”, “icmp”, etc.
Puerto: en este caso, se registrará el puerto al cual se invoca desde el lado del cliente. En el ejemplo del servidor de aplicaciones, el puerto sería 80.
Comentarios: en este campo se colocarán comentarios que nos guíen sobre qué afecta esa regla. Por ejemplo, documentar nuestros archivos con algo del estilo “Sólo pasan desde Internet hacia 10.100.150.10” puede ser muy útil si queremos en algún momento modificar las reglas.

Existe un archivo importante que es /etc/shorewall/masq. En ese archivo configuraremos las diferentes redes que enmascararán sus direcciones IP cuando deban acceder a otras. En nuestro caso, lo haremos con los puestos que salgan a Internet y que utilicen un puerto diferente del 80, redirigido al proxy que tenemos en el puerto 8008.

El formato de este archivo también se basa en el uso de columnas, o campos, y sus usos son los siguientes:

Interface: se especifica en este caso cuál será el destino del cual se espera recibir respuestas cuando se enmascare una dirección o rango de direcciones IP. Por ejemplo, si pensamos en todo Internet, tendremos que colocar 0.0.0.0/0.
Dirección o rango de origen: aquí configuraremos la dirección o rango de direcciones IP que serán enmascaradas cuando deban acceder alguna dirección especificada en el campo anterior. Por ejemplo, para los puestos cliente, tendremos que colocar 10.100.100.0/0.

Por último, veremos un archivo más, que también se debiera editar o crear, y que es el /etc/shorewall/policy. Este archivo contendrá políticas generales, fuera de lo que son las reglas, que se aplicarán al firewall en general. Su formato en sí es muy parecido al /etc/shorewall/rules, también basado en columnas:

Cliente: como vimos antes, desde donde se generan las conexiones.
Servidor: ídem, hacia donde van las conexiones.
Política: qué se hará en forma predeterminada. Las acciones también podrán ser “ACCEPT”, “DROP”, etc.
Nivel de log: en este campo definiremos si queremos que se genere un registro en el log cada vez que se produzca un error (“err”), sólo por cuestiones informativas (“info”), u otros casos. Tengamos en cuenta que puede ser bastante grande un archivo de log cuando el tráfico es fuerte, por lo que esto se debe regular bien.

Ahora, definiremos qué es lo que se hará en cada zona, dependiendo de las premisas de que partimos. Para ello, editaremos o crearemos el archivo /etc/shorewall/rules. Veamos cada una de estas premisas.

Premisas 1 y 3: Todo cliente que quiera salir a Internet directamente, y sin configurar su proxy en su sistema, deberá ser redirigido automáticamente al puerto 8008. Sólo habrá un cliente que tendrá permitido salir a Internet sin pasar por el proxy, y tendrá la dirección IP 10.100.100.10.

Para lograr esto, tendremos que pensar que el cliente será cualquier máquina de la red 10.100.100.0/24 que quiera salir a internet. Por lo tanto, el cliente será “lan”, el servidor será el puerto 8008, el protocolo será de la familia “tcp”, el puerto será el 80, y la acción a realizar será “REDIRECT” con todos ellos, a excepción del cliente 10.100.100.10, que podrá salir a Internet sin pasar por este proxy. La regla resultante será, entonces:

REDIRECT lan:!10.100.100.10 8008 tcp www

Notemos que en la sección del cliente, estamos agregando todo lo que provenga de “lan”, y exceptuando la dirección 10.100.100.10 colocándole un “!” antes. Si tuviéramos más máquinas que exceptuar, las agregaríamos separadas por comas, sin espacios. Si por ejemplo, tuviéramos que exceptuar las direcciones 10.100.100.10 y 10.100.100.9, esa expresión se vería reemplazada por “!10.100.100.10,10.100.100.9”.

Premisa 2: Todo protocolo de red diferente de la navegación por Internet deberá salir al mundo utilizando enmascaramiento de direcciones IP.

Para lograrlo, veamos cómo configurar el archivo /etc/shorewall/masq siguendo los lineamientos que vimos antes:

0.0.0.0/0 10.100.100.0/0

Así de sencillo es configurar el enmascaramiento de direcciones IP.

Premisa 5: Se implementará un servidor Web interno, que no deberá ser accedido desde afuera de la red. Su dirección IP será 10.100.100.50.

En este caso, tendremos que realizar, como acción un NAT en el destino, por lo que la acción se llamará “DNAT”. El cliente será Internet en general, el servidor estará en la zona dmz, específicamente en la dirección 10.100.150.10, el puerto invocado por el cliente será el 80, pero el sistema tendrá que enviar los pedidos desde este puerto al 8080. La regla entonces quedará así:

DNAT wan dmz:10.100.105.10:8080 tcp 80

Premisa 6: Se deberá implementar un servidor de aplicaciones que utilice los datos de la base que se encuentra en un servidor con dirección IP 10.100.100.100. El servidor es PostgreSQL, por lo que se accede a sus datos a través del puerto 5432. El software del servidor de aplicaciones es un Tomcat, que usa el puerto TCP 8080 para funcionar.

En este caso el tema se pone un poco, y solo un poco más complicado. El cliente, como vemos, es el servidor de aplicaciones que tiene la dirección 10.100.150.10 y está ubicado en la zona “dmz”, y el servidor se encuentra en el puerto 5432 de la dirección IP 10.100.100.100 de la zona “lan”. Lo que se hará a nivel de acción será aceptar estos pedidos. La regla entonces quedará así:

ACCEPT dmz:10.100.150.10 lan:10.100.100.100 tcp 5432

Bueno, tal parece que ya tenemos todas las reglas en su lugar. Sólo nos queda una sección de la configuración que tocar a nivel de reglas, y es el archivo /etc/shorewall/policy.

Una de las cosas que deberé especificar es que todo lo que no esté explícitamente aceptado, cuando se trate de una conexión desde Internet hacia la red interna, o hacia el mismo firewall, estará denegado. Eso se hace sólo con declarar lo siguiente:

wan all DROP err

Al agregar como servidor “all” le especificamos a Shorewall que no importa a qué zona un paquete de red se esté dirigiendo, deberá ser eliminado.

Si lo que deseo es un nivel de logueo exhaustivo, en este archivo declararé las reglas:

lan all ACCEPT info

fw all ACCEPT err

Con estas reglas, ya no queda mucho más por configurar para lograr las premisas que fueron planteadas.

Ahora, podremos modificar el archivo /etc/default/shorewall cambiando la entrada:

startup=0

...por:

startup=1

IMPORTANTE: Veamos que no hemos habilitado el SSH hacia nuestro firewall desde ninguna zona. Si lo queremos dejar habilitado para conectarnos desde nuestra red interna, deberemos agregar una entrada como la siguiente en /etc/shorewall/rules:

ACCEPT lan fw tcp 22

...y si queremos acceder a nuestro firewall desde Internet, la regla cambiará para tomar esta forma:

ACCEPT wan fw tcp 22

Con esto configurado, sólo debemos ejecutar Shorewall con el comando:

# /etc/init.d/shorewall start

Interfases gráficas

Si bien vemos que la configuración de un firewall profesional, gracias a Shorewall es notablemente sencilla, podría ocurrir que un fanático de los navegadores se encuentre en medio de nuestra tropa de sysadmins, por lo que tendremos que implementar alguna ventana que lo haga felíz.

Una de las aplicaciones difundidas, y de mucho uso, es el denominado “Webmin”, que posee un módulo específico para la administración de firewalls basados en Shorewall.

Recordemos que Webmin usa generalmente el puerto 10000 para funcionar, por lo que antes de activar el firewall debemos agregar una regla que nos permita conexiones desde una determinada red hacia él.

Esto lo lograremos agregando a /etc/shorewall/rules una línea como la siguiente si queremos que se acceda Webmin desde la red interna:

ACCEPT lan fw tcp 10000

...o como la siguiente si queremos que se acceda desde Internet:

ACCEPT wan fw tcp 10000

Ahora instalamos el paquete webmin, su módulo de control de Shorewall, relanzamos los procesos de shorewall con:

# /etc/init.d/shorewall restart

Y con esto terminamos nuestra tarea, dejando a nuestro sysadmin amigo con una sonrisa en su cara, y una ventanita como ésta en nuestro navegador:

Conclusión

Con estos pocos comandos, como vimos más arriba, hemos configurado un firewall de características profesionales. Con él tenemos protegida nuestra red interna, redirigida nuestra red externa, y hasta contamos con una zona desmilitarizada donde podremos colocar nuestro servidor de aplicaciones conectado a una base de datos sólo por un puerto.

Un aspecto también importante de este tipo de configuraciones es que salvo un consumo demasiado elevado a nivel de tráfico de red, máquinas muy chicas, y que sólo posean la capacidad de tener varias tarjetas de red genéricas pueden servir para armar un verdadero sistema de seguridad perimetral. Espero que hayan disfrutado de los conceptos aquí volcados, y de la configuración de ejemplo que hemos realizado.

Los espero el mes que viene, con más artículos técnicos para depilarnos el flequillo. ¡Nos vemos!

Sobre OpenSolaris, OpenIndiana, IllumOS, Solaris 11, y demás

2011-01-16T18:37:00.001-03:00

Bueno, ya se esperaba el momento en el cual comience a hablar del tema, y aprovechando mi actual incapacidad de moverme demasiado, que espero, en breve deje de ser tal y me permita volver a buscar el mate y la pava en el piso, acá va un post sobre lo que creo, deberá ocurrir en el breve lapso de tiempo que es este año con las distros más comunes de la tecnología Solaris.
Ya todos conocen la historia, y deben de estar mirando al mundo de los que seguimos y/o codificamos para estas distros como "esos tipos que pierden el tiempo con algo que nadie usa".
Lo cierto es que estamos en uno de esos momentos en los que la inflexión se hace notar demasiado, y la diáspora entre los miembros de una comunidad puede resultar en dos cosas, muy bien diferenciadas:
a) Varias comunidades que se tienen simpatía por haber tenido una raíz común en algún momento de su historia.
b) Un montón de gente que cada tanto se junta en un bar a hablar de las buenas épocas y nada más.
c) La unión de todas las personas que están metiendo los dedos en cada una de las distros para armar una comunidad mucho más grande y con mejores productos.
Creo que había dicho dos...bueno, son tres las opciones. Tengo derecho a meter la pata a veces.
Y cuál es el estado actual de las cosas?
Bien, en la lista de OpenSolaris la gente se mete para ver en qué momento alguien, quizá el mismísimo Jim Grisanzio declara la muerte por cierre del sitio. La punta la metió el grupo de OpenSolaris de Madrid pidiendo que archiven su parte del sitio, y que cierren su lista de correo, dado que no tiene más nada que ver con un grupo de personas que siguen al código abierto. Yo ya lo decía hace tiempo, la madre patria para algunos se suma a la tendencia del paro...bueno, algo de humor negro en estos tiempos. Quizá algún gobernante lea esto y se dé cuenta que es importante hacer algo, pero no con la lista de OpenSolaris de Madrid, sino con el país que le toca conducir. Si quiere meterse en la lista de OpenSolaris de Madrid, ya es tarde...espero que no sea una tendencia.
El canal IRC de la misma lista sirve para que la misma gente que desarrolla en otras distros tome algo de conocimiento sobre las cosas que allí se cocinan, que no son muchas, porque dicho sea de paso, el horno no tiene gas hace rato.
Eso nos lleva a la lista de illumOS, donde pareciera que hay un poco más de movimiento, claro que tenemos a Garrett como moderador-censor-definidor de cada línea de código que se mete allí, y a algún que otro programador malhumorado que cada tanto pone el grito en el cielo porque siente que eso no es democrático.
Quién le dijo a esos programadores que algo democrático podría salir de una iniciativa como esa? Ojalá que así sea, al menos pareciera que hay esfuerzos para que esa sea la tendencia, pero por ahora, parece que la tendencia es seguir los caminos y designios de los mismos malhumorados de unas líneas más arriba.
En este caso el canal de IRC es bastante más divertido. Se definen porciones de código, se piensa cuál será el alcance real del esfuerzo de illumOS, se ahuyenta a todo programdor que tenga ganas de comenzar con esto, que generalmente es alguien que no entiende que si bien está mejor organizado que la mayoría de los IRC's de otras distros, se va a sentir mal antes de poder compilar el código mínimo para tener un illumOS en ejecución.
Luego tenemos OpenIndiana, que parecía como la salvación de la gente que alguna vez apostó mucho de su tiempo en la implementación del viejo OpenSolaris. Esta distro funciona, es una distro en sí misma, lo que significa que una persona no debe ser experta en C/C++, Python, Java y demás para poder instalarla, y dentro de todo se ve bastante amigable.
El problema es el que se esperaba: no hay tantos paquetes directamente en el repositorio, por lo que todo el tiempo salen propuestas para que aparezcan nuevos que contengan estos paquetes. Claro está, si alguien viene de la vieja guardia, como es mi caso, entenderán al segundo cómo hacer para implementar OpenOffice, PostgreSQL, o demás con el sistema de paquetería SVR4, que tantas alegrías me ha dado.
El canal de IRC de esta distro también está más interesante. Mucha gente propone cosas, y mucha otra le explica a la primera que las manos no alcanzan para todo lo que se quiere hacer. Por lo menos en este caso es más democrático que en el anterior.
Solaris 11 lo bajé, lo instalé, lo maldije, y lo desinstalé. Pesa una barbaridad (de seguro alguien del oráculo va a venir a decirme que es mentira, que el uso de CPU en esta distro es un 95,23% menor que en los anteriores desarrollados por los tipos de Sun, que los viejos programadores no sabían nada, que el color rojo es más lindo que el violeta, y otra estupideces), pero tiene novedades interesantes en lo que a ZFS respecta, por ejemplo. La versión es superior a la que teníamos en nuestro OpenSolaris, y también que en el OpenIndiana.
Claro está, tiene el pequeño problema de ser software privativo que el señor Larry entre cirugías y regattas nos permite usar porque es buen chabón.
Pero tengamos en cuenta una cosa importante: si las versiones se comienzan a abrir, entonces estamos ante el problema de no saber en el futuro qué es lo que se podrá o no se podrá montar.
Alguien podría tener un Ubuntu implementado, con su flamante módulo de ZFS, y ver cómo le aparece un mensaje de error que hace referencia a que la versión que tiene es más nueva que la que el sistema operativo soporta.
O alguien puede querer mudar sus containers de una máquina con un ZFS a otra y ver cómo no funciona la migración, alimentando todos los foros del mundo XXXSolaris para que alguien le tire una soga y le permita volver a levantar sus sistemas operativos virtualizados. Parece mentira ne esta época hablar de eso, no?
Por mi parte, mi actitud frente a todo este descontrol es bien clara: seguiré con un grupo de personas con las cuales cada vez que nos juntamos sentimos que estamos haciendo cosas grossas por cada miembro de la comunidad de acá y del resto del mundo, seguiré adaptando paquetes para que se puedan levantar en cualquiera de las versiones de XXXSolaris que aparezcan, y se las seguiré ofreciedo al mundo. Porque sí, porque soy taaaan copado...
Salutte per tutti.

DRAFT – Compilación de actualizaciones

2010-07-27T22:51:00.001-03:00

Para compilar el código fuente que cada cierto tiempo se libera, se deben seguir determinados pasos, así como se debe contar con determinada configuración de ambiente de compilación.

Este capítulo intenta simplificar este proceso a través de una lista de sencillos pasos. La fuente de consulta en caso de dudas es http://hub.opensolaris.org/bin/view/Community+Group+on/devref_toc .

Armado del ambiente de compilación

Como regla general, recordemos que para compilar la versión "N", siempre tendremos que estar utilizando, como mínimo, la versión "N-2". Eso quiere decir que si partimos de la versión onnv_142, podremos compilar la versión onnv_144, por ejemplo. Luego, podremos compilar la versión onnv_145, o la onnv_146.

Instalaremos ante todo, desde el repositorio /dev de opensolaris.org, el paquete "developer/versioning/mercurial".
Luego, tendremos que instalar el paquete "developer/opensolaris/osnet" desde el repositorio "extras" de pkg.sun.com, para el cual necesitaremos seguir determinados pasos, a saber:

- Tener una cuenta. Si no la tenemos, ingersaremos a http://pkg.sun.com/register, y la sacaremos.
- En el mismo sitio ingresaremos, y solicitaremos nuestro certificado para el repositorio "extras" de OpenSolaris.
- En la pantalla donde se nos ofrece bajar la clave y el certificado, bajaremos ambos dos. Es importante guardarlos como si fueran hechos de oro y brillantes.
- Ejecutamos la siguiente secuencia de comandos:
# mkdir -m 0755 -p /var/pkg/ssl
# cp -i OpenSolaris_extras.key.pem /var/pkg/ssl
# cp -i OpenSolaris_extras.certificate.pem /var/pkg/ssl
# pkg set-authority -k /var/pkg/ssl/OpenSolaris_extras.key.pem -c /var/pkg/ssl/OpenSolaris_extras.certificate.pem -O https://pkg.sun.com/opensolaris/extra/ extra
# pkg list -a 'pkg://extra/*'
# pkg install developer/opensolaris/osnet

Si nuestra instalación estaba limpia, cuando instalemos este paquete veremos que también se instalan:

- developer/build/onbld
- library/gnome/base-libs
- developer/parser/bison
- library/libsigsegv
- system/library/mozilla-nss/header-nss
- system/management/snmp/sea
- SUNWwbdev
- developer/java/jdk
- web/server/apache-13
- SUNWcsl
- library/apt-util-13
- SUNWsasnm
- data/docbook
- SUNWjsnmp
- developer/library/lint
- SUNWadmj
- developer/astdev
- text/gnu-gettext
- web/server/apache-22
- SUNWwbapi
- developer/gcc-3
- library/tooltalk
- library/apr-13
- cde/cde-runtime
- system/header
- SUNWlibms
- library/motif
- library/nspr/header-nspr
- library/apt-util-13/apr-ldap
- SUNWwbcou
- developer/gnu-binutils
- SUNWlibC
- developer/lexer/flex
- developer/macro/gnu-m4
- system/library/liblayout

Ahora, debemos instalar el compilador que usaremos. Si instalamos el compilador SunStudio 12 Update 1, tendremos infinitos errores de compilación, dado que el que está homologado, al menos al día de la fecha (07/2010) es el SunStudio 12 (sin el Update 1).
Entonces, tendremos que bajar dicho compilador del url http://hub.opensolaris.org/bin/view/Community+Group+tools/sun_studio_12_..., que nos llevará nuevamente a un sitio donde necesitamos nuestro Sun Online Account.
En mi caso particular, el archivo que bajé es el sunstudio12-patched-ii-2009Sep-sol-x86.tar.bz2, por lo que ejecutaré, para instalarlo, los siguientes comandos:

$ su -
# cd /opt
# mkdir SUNWspro
# cd SUNWspro
# tar jxvf /export/home/hecsa/Downloads/sunstudio12-patched-ii-2009Sep-sol-x86.tar.bz2
...

Compilación del nuevo código

Con esos paquetes instalados, ya podremos bajar el código fuente nuevo.
Debemos ejecutar los siguientes comandos:

$ su -
# cd /opt
# mkdir sources
# cd sources
# hg clone ssh://anon@hg.opensolaris.org/hg/onnv/onnv-gate onnv_144
# cd onnv_144
# hg update onnv_144

Aceptamos el fingerprint si es la primera vez que ingresamos mediante la utilidad "hg" de Mercurial utilizando ssh. Al finalizar este proceso, tendremos un nuevo directorio llamado "/opt/sources/onnv-gate" con aproximadamente 862 MB. Este valor puede variar según la versión que se esté bajando.
También debemos, para esta versión, bajar los binarios cerrados, y los de criptografía.
En nuestro caso, para esta versión, lo haremos desde los URL's: http://dlc.sun.com/osol/on/downloads/b144/on-closed-bins-nd.i386.tar.bz2 y http://dlc.sun.com/osol/on/downloads/b144/on-crypto.i386.tar.bz2.
Para hacer uso de estos dos archivos, ejecutaremos estos comandos:

# cd /opt/sources/onnv_144
# tar jxvf /export/home/hecsa/Downloads/on-closed-bins-nd.i386.tar.bz2
...
# mv /export/home/hecsa/Downloads/on-crypto.i386.tar.bz2 .

Copiaremos y modificaremos el archivo opensolaris.sh:

# cd /opt/sources/onnv_144
# cp usr/src/tools/env/opensolaris.sh .
# vi opensolaris.sh

Modificaremos las siguientes líneas:

GATE=testws;
por
GATE=onnv_144;

CODEMGR_WS="/export/$GATE";
por
CODEMGR_WS="/opt/sources/$GATE";

STAFFER=nobody;
por
STAFFER=root;

Ahora, configuraremos las variables de ambiente necesarias para realizar la compilación:

# export PATH=/opt/onbld/bin:/opt/SUNWspro/bin:$PATH

Al final del archivo agregamos estas dos líneas:

i386_LINT=/opt/SUNWspro/bin/lint; export i386_LINT
amd64_LINT=/opt/SUNWspro/bin/lint; export amd64_LINT

Listos para la compilación, ejecutaremos:

# nightly ./opensolaris.sh &

Si queremos ver cómo van las cosas que estamos haciendo, sólo tendremos que verificar el archivo log/nightly.log, utilizando el comando "tail -f /opt/sources/onnv_144/log/nightly.log". También podemos verificar la existencia de varios comandos "dmake" en plena ejecución con el comando "prstat -a".
Nótese que en forma predeterminada tendremos en la variable NIGHTLY_OPTIONS del archivo opensolaris.sh la letra "p", lo que significa que el comando nightly generará, al final de la compilación, un directorio conteniendo todos los paquetes que se han implementado.
Esos paquetes conforman un repositorio que se encuentra en "/opt/sources/onnv_144/packages".

Sobre Cyborgs y demás yerbas

2010-06-20T02:01:00.001-03:00

Para los que están acostumbrados a ver salir de mis neuronas artículos sobre tecnologías de código abierto, GNU/Linux y OpenSolaris, u otros más pegados a ciencias duras, la inclusión de éste que tienen en Su poder puede despertar una sensación de considerar que el postre tenía mucho moscato y me cayó mal, dejando casi sin oxígeno al pobre cerebro que intento llevar sobre mis hombros con algo de esfuerzo y dignidad.

Lo cierto es que este tema siempre me interesó. Lo analicé varias veces sin demasiada profundidad, al menos eso es lo que ahora pienso. Veamos cómo encarar un tema que en un principio puede sonar futurista, y casi salido de un libro de ciencia ficción, pero que se mete cada día más en nuestra vida de una forma casi imperceptible, y para quedarse. Hablemos de cyborgs.

¿Qué es un cyborg?

La palabra “cyborg” es un acrónimo de “cybernetic organism”, u organismo cibernético. Y la cibernética no es más que una ciencia estudiosa de las “analogías entre los sistemas de control y comunicación de los seres vivos y los de las máquinas; particularmente, el de las aplicaciones de los mecanismos de regulación biológica a la tecnología” (entre comillas por pertenecer al diccionario de la Real Academia Española").
Simplificando y contrastando con la imagen que el común de la gente tiene, un cyborg es un organismo que posee parte de su tejido orgánico, y parte conformado por dispositivos mecánicos, o electrónicos.
Al hablar de “un organismo”, y no un “ser humano”, estamos dividiendo las aguas y separando éste de conceptos como el del “androide”, que es un autómata con aspecto de ser humano. Un cyborg no tiene por qué tener un aspecto humano.
Un ejemplo de ello son los experimentos que se han hecho en una universidad de Surrey (Inglaterra) utilizando un cerebro de rata contenido en un recipiente capaz de enlazar terminaciones nerviosas a través de un dispositivo bluetooth (enlace inalámbrico para distancias cortas, se utiliza en redes de área pequeña, o portátiles, y de allí su nombre “PAN”) con un robot de tres ruedas y varios juegos de sensores dispuestos para reemplazar ojos, nariz y oídos.
Por suerte, la sociedad protectora de animales estuvo presente en cada uno de los cientos de experimentos que se hicieron en Surrey. Fueron cientos hasta que se terminó de entender cómo hacer para encender los mecanismos del robot usando el cerebro de la rata. Sí, mataron cientos de ratas hasta que le dieron en el clavo.
Es especialmente interesante el momento en el que el robot comienza a funcionar como se esperaba, y podemos ver cómo la rata nota que algo le está faltando (todo su cuerpo), por lo que comienza a mover las ruedas del robot de forma desesperante, como buscando algo que no sabemos qué es.
Por suerte, nos hacemos llamar humanos, y no escatimamos en gastos cuando de lágrimas de rata se trata.

Y yo pensaba que un implante de pelo era antinatural

Si ya lloramos un poco pensando en la pobre rata, veamos ahora un ejemplo de aplicaciones claramente cibernéticas sobre seres humanos.
Tal parece que nuestro querido amigo Kevin Warwick, también de Inglaterra, pero esta vez desde Coventry (¿será sólo una casualidad que sean todos ingleses, y que vengan de ciudades con nombre de aire acondicionado?), decidió llevar sus estudios sobre cibernética un paso más adelante, y un buen día luego de una sobredosis de “El hombre nuclear” desarrollo algo bastante imaginativo.
Su desarrollo se denominó “Proyecto Cyborg”, y (por ahora) constó de dos fases.
En la primera (“Cyborg 1.0”) creó un implante subcutáneo que un grupo de cirujanos dirigidos por él mismo le implantó en el antebrazo.
Este implante consta de un transmisor RFID (Radio Frequency Identification) gracias al cual la identidad de Kevin es verificada en cada lugar por el cual se mueve, abriendo automáticamente puertas y ventanas, o encendiendo las luces y su computadora cuando él se encuentra cerca.
Para que tengamos una idea un poco más acabada del nivel de desarrollo que tiene la tecnología RFID en este momento, ya hay cadenas de supermercados que incorporan etiquetas de este tipo en sus alimentos, sabiendo automáticamente cuándo ingresa, es vendido, o vence. En base a eso, se disparan órdenes de compra automáticas a los proveedores para nunca quedar desabastecidos, o para alimentar la estacionalidad de nuestras costumbres como consumidores.
La segunda fase (“Cyborg 2.0”) es aún más polémica, dado que desarrollo un dispositivo de interface neuronal que luego fue construido por el Dr. Mark Gasson. Este dispositivo fue luego implantado en el sistema nervioso de nuestro amigo Warwick, quien en una primera etapa logró controlar un brazo robot con su pensamiento. Así es, conectó su sistema nervioso a la entrada de internet de la Universidad de Columbia, en Nueva York, y desde ese punto pudo controlar este brazo robotizado.
La broma clásica en esa universidad por aquellos tiempos (2002) era que con tanta pornografía dando vueltas en internet, era de esperar que Kevin quisiera un nuevo brazo.
Como a Warwick no lo satisfizo ese experimento, le conectó un distribuidor de señales a su esposa, con quien aún hoy en día puede mantener contactos en forma telepática utilizando también internet como medio de enlace mundial.

No todo son rosas

Así es, no todo es color de rosa. Algunos ven el mundo en blanco y negro, como le ocurría al artista plástico Neil Harbisson (sí, adivinaron, también es inglés, pero esta vez de Londres).
En sus épocas de estudiante Neil conoció a Adam Montandon, un licenciado en cibernética de la Universidad de Plymouth, con quien trabajó en el desarrollo de un dispositivo denimonado “Eyeborg”.
Este aparato (el eyeborg, no Neil) consta de un sensor frontal que se dispone entre ambos ojos, y una serie de interconexiones que llegan hasta el oído, de forma tal de permitir la conversión de los colores a sonidos.
Esta invención hizo merecedores a Neil y Adam del premio británico a la innovación. Neil, por su parte, recorrió toda Europa y le asignó a cada país un color que lo identificaría. Su obra se denomina “Capital Color of Europe”.
Ya que los colores se pudieron traducir en sonidos, Neil llevó esto un escalón más arriba convirtiendo los sonidos en colores, traduciendo las cien primeras notas de varias partituras famosas en colores, consecuentemente entregándonos una espléndida obra denominada “Color Scores”.
Por suerte, esta historia tiene un final felíz. No matamos ratas, ni esclavizamos esposas controlando cada uno de sus pasos a través de internet.

Cyber-cucatrap

En Japón no podían quedarse atrás. En este caso, el desarrollo se basó en un dispositivo de sólo tres gramos de peso (el doble del de una cucaracha, que soporta cargar hasta veinte veces su masa corporal) aplicado sobre la cabeza de una cucaracha.
Así, se creó una cucaracha que aún estando viva es controlada en forma remota, pudiendo influenciar al resto de su grupo. Me recuerda a ciertos políticos, pero debo ser yo que siempre tengo malos pensamientos.
Se logró modificar el recorrido de un grupo de insectos y hasta su comportamiento frente a determinadas circunstancias.

Volviendo a la tierra

Pisando nuevamente el suelo, nos encontramos con ejemplos de cyborgs mucho más cotidianos. Una persona que tenga implantado un marcapasos puede orgullosamente ubicarse dentro de este grupo, ya que sin este dispositivo no podría siquiera vivir.
En general, hemos dejado de ser seres que se mueven dentro de la pura naturaleza y nos convertimos en dependientes de la tecnología a niveles tales de caer en un colapso nervioso cuando se agota la batería de nuestro celular, o de nuestro reloj pulsera. Ya no sabemos siquiera mirar al cielo para reconocer por la posición de las estrellas si es medianoche o estamos cerca de la madrugada del día siguiente.
Tampoco podemos oler un alimento y saber cuándo está por descomponerse, nos limitamos a verificar la fecha de vencimiento de una lata. Y lo peor, confiamos ciegamente en que un día antes de ese vencimiento nuestro cuerpo estará a gusto con ese alimento, y un día después estaremos ante las siete plagas por ingerirlo.
Por lo tanto, en menor medida (¿realmente menor?) nos hemos convertido en cyborgs. O mejor dicho, nos han obligado a aceptar nuestra característica cyborg casi sin chistar.
Hoy recordaba con una compañera la frase “resistirse es fútil, serás asimilado”, acuñada por la legendaria serie “Star Trek” y sus colonias Borg. Hagan una pausa para suspirar con “SevenOfNine” y sigan adelante.
Desmenuzando algo de la sociedad en la que he nacido, encuentro que esta frase se hace carne en mí. No puedo resistirme a volverme un cyborg; desde que nací, y aún antes de haberlo hecho, las máquinas han sido un factor de supervivencia para mí. Me he vuelto un adicto a ellas, esta sociedad insertó en mi cabeza un sistema de control neuronal que me impulsa a considerarlas una necesidad, aún cuando realmente no lo sean.
No es que hayamos perdido la cordura, es la triste realidad. Si cuando ordenás tu placard te aparece la pantalla del Tetris delante tuyo, es momento de consultar con un profesional, y tirar la PlayStation al tacho de basura.

Algo bueno para cerrar

Basta de mala onda. Seamos felices, encarguemos un Big Mac, y veamos el mundo a través del Google Earth.
Hace menos de un año tuve el gusto de compartir una conferencia con Rómulo Speratti, un miembro del CaFeLUG (Capital Federal Linux Users Group) tal como lo soy yo. Él se dedico a asombrar al público de la Universidad Tecnológica Nacional formándolos sobre los desarrollos que existen en materia de software libre dedicados a personas minusválidas y discapacitadas. No voy a ahondar en la diferencia que existe entre cada tipo de discapacidad porque si hay alguien que realmente sabe de eso es él, yo soy apenas un neófito, y desde ese día, otro entusiasta esperando en algún momento poder ser un colaborador de sus proyectos.
Tan abrumado salí de su conferencia, que me puse a investigar más a fondo sobre los temas que había tocado.
Concretamente, tuve el gusto de implementar un software denomiado eViaCam que sirve para que personas cuadripléjicas, sólo girando su cara, puedan controlar una computadora en forma completa accediendo a páginas web, escribiendo y leyendo mails, o realizando cualquier tipo de trabajo que con una máquina es posible.
También implementé el sistema Orca en mi computadora, que lee el texto que tengo delante de mí, o magnifica cualquier parte de la pantalla para que pueda verlo más cómodamente.
Me queda la felicidad de estos inventos, y de recibir a veces algún mail de sus listas de correos, con la ilusión de que fueron escritos por personas que de no haber sido desarrollados, no hubieran podido decirle al mundo lo que sienten.
Hasta la próxima, mis queridos cyborgs.

OpenSolaris y sus servicios

2010-05-14T01:22:00.010-03:00

En este artículo se aborda la forma que tiene OpenSolaris de manejar sus servicios.
Veremos que ha cambiado bastante desde la época de Solaris 8 ó 9, e inclusive respecto de la forma en la cual se trabajaba con Solaris 10.
Tenemos, en el caso de OpenSolaris, varias herramientas que nos permitirán armar el árbol de precedencia de procesos a la hora de lanzar un servicio en particular, así como la forma en la cual se paralelizará éste con otros.
Aprendamos a utilizarlos, serán nuestros amigos en la automatización de tareas de arranque, y su diagnóstico nos hará muy sencilla la vida cuando aparezca algún problema.
Para los que creyeron que los artículos anteriores eran light, acá va un desafío a sus neuronas.

Todo es historia

Ya hace un buen tiempo atrás aparecieron tecnologías de hardware que permitieron contar con herramientas de monitoreo y detección de fallas en forma automática. Elementos tales como el termómetro interno nos permiten conocer la temperatura de nuestro procesador, y en base a ello decidir qué hacer en caso que se eleve demasiado. No es raro que alguien esté escribiendo un documento larguísimo, y que antes de salvarlo descubra que su máquina se apaga por tener un ventilador tapado con pelos del perro Caniche Toy que le recomendaron comprar para cuidar la casa.

En el caso de servidores de mayor porte, hasta tenemos indicadores que nos dicen cuándo alguna pieza debe ser reemplazada. Así, por ejemplo, tenemos discos, memorias y otras piezas de hardware que tienen como característica ser “hot swap”, es decir, que se pueden reemplazar aún con el sistema funcionando, sin generar ningún tipo de inconveniente. La redundancia es muy común en este tipo de sistemas.
Ahora bien, a nivel de hardware pareciera que nuestra vida está simplificada. ¿Qué pasa a nivel de software? Hasta hace un tiempo atrás, los diferentes sabores de Unix, tanto originales como clónicos, sólo contaban con la posibilidad de lanzar servicios en forma secuencial, y en el mejor de los casos con algún grado de paralelismo.
La forma de monitorear servicios, así como de lograr su lanzamiento considerando dependencias se basaba casi de forma exclusiva en infinidad de scripts no estandarizados que cada sysadmin armaba. Y que debuggeaba cada vez que un servicio se caía.
No era extraño poder casi adivinar la cantidad de versiones de scripts creados, y su fecha de release sólo con mirar el CV de un sysadmin. Los cambios de empresa coincidían con una “prueba productiva” que generalmente terminaba con un botellazo y algunas palabras irreproducibles por parte de sus superiores.

Antes configurábamos un script en el directorio /etc/init.d, que luego linkeábamos simbólicamente ("ln -s") hacia los directorios /etc/rcX.d con un nombre que comanzaba con “S” si queríamos que se ejecuten con el argumento “start”, o con “K” si el argumento debía ser “stop”. Pero si necesitábamos verificar la existencia de un servicio previo al lanzamiento de otro, todo volvía a depender de scripts. Y si algo fallaba, lo más común era buscar con comandos como “grep” algún tipo de pista en los logs del sistema.
Teniendo esto en cuenta, OpenSolaris modificó este subsistema al punto de crear un framework completo de gestión de servicios. Así logramos identificar procesos correspondientes a servicios en un único log por cada uno de ellos, separándolos de cualquier otro proceso lanzado por un usuario.
También se generó un subsistema que permite saber en qué momento debe ser ejecutado cada servicio, sus dependencias, las reglas que implican su relanzamiento, la cantidad de relanzamientos antes de considerar que hay una falla que requiere intervención humana, y un formato estandarizado de configuración para todos y cada uno de ellos.
Y si tenemos algún sysadmin enamorado de los scripts, le permitimos que los siga usando como hasta ahora, sin tener que modificar nada.

Conceptos previos

Bueno, creo que todos ya sabemos lo que es un servicio. ¿Lo sabemos? Está bien, para los que no lo tienen muy claro, acá van algunas definiciones de “servicio”:

- En *nix, lo que se ejecuta en forma no-interactiva, por lo que no debe ser lanzado por un usuario humanamente logueado en nuestro sistema.
- En España, es un sinónimo de “baño”.
- Para el ciudadano común, aquello que le permite tener luz, agua, y gas, y que le es cortado cuando no paga, y a veces cuando paga también.

Por ejemplo, cuando ingresamos a un sistema mediante SSH o Telnet, lo hacemos gracias a un servicio que “escucha” en un determinado puerto esperando a que algo, como nuestro pedido de ingreso, ocurra. Sin caer en lo obvio, entendemos ahora por qué se llama a los sistemas que nos proveen algún servicio (suenen trompetas), "servidores".
El framework que en OpenSolaris se creó para poder manejar estos servicios recibió el nombre de SMF (Service Management Framework). Él permite estandarizar, por ejemplo, el modelo de estados y la convención de nombres. Asigna dependencias y describe cada uno de los métodos utilizados para rearrancar un servicio en caso de fallas o caídas. Todo esto se encuentra controlado por un proceso demonio llamado “svc.startd”. Es él quien se ocupa de recibir los avisos de procesos o servicios caídos, siendo quien los levanta o notifica en base a las especificaciones que se hayan asignado.
El proceso svc.startd es invocado en forma automática cuando el sistema operativo arranca, de allí que veamos en una de las líneas del archivo "/etc/inittab":
smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog El nombre de la rosa

De la misma forma en la cual si queremos referirnos a alguien lo hacemos por su nombre y apellido, cuando querramos referirnos a un servicio lo debemos hacer por medio de su nombre.
Entonces, lo primero será saber cómo se nombran los servicios.
En OpenSolaris el nombre de un servicio se denomina FMRI, siglas de “Fault Management Resource Identifier” (más adelante extenderemos la explicación sobre por qué se ha asignado este nombre).
Veamos primero cuáles son los campos que existen en su nombre, para luego llegar a un ejemplo práctico que pueden seguir en sus propias máquinas. Los campos existentes en un nombre de servicio son:

- scheme: Indica el tipo de servicio que se está invocando. Puede ser “svc” si se trata de un servicio manejado por SMF, o “rc” si mantiene el viejo esquema de scripts. ¡Sí, desde esta facilidad también podemos administrar los viejos scripts localizados en /etc/init.d!
- location: Este campo indicará el servidor o sistema donde el servicio esté declarado, o en ejecución. Normalmente estaremos declarando “localhost” en este campo.
- functional category: Este campo indicará el tipo de servicio que se está invocando, desde un punto de vista funcional. Según esta característica puede ser:
- application: Se está haciendo referencia, por medio de este campo, a un programa o demonio en particular. El que se nombre de esta forma implicará que no tiene nada que ver con alguna de las categorías anteriores. Ejemplos de “application” son “graphical-login”, que nos mostrará la ventana gráfica por medio de la cual ingresar nuestro usuario y contraseña, o “net-snmp”, que nos permitirá manejar la gestión de servicios SNMP (simple Network Management Protocol).
- system: Se está invocando un servicio independiente de la plataforma. Ejemplos de esta categoría son “cron” (el gestor de tareas agendadas en forma repetitiva en OpenSolaris o cualquier *nix), o “rbac” (Role Based Access Control).
- device: Se nombra un servicio que ayuda a cubrir las dependencias originadas en el hardware, como ser algún dispositivo del cual se requiera una entrada o salida para funcionar.
- network: Refiere servicios de red que ya han sido convertidos de “inetd”. Ejemplos de esta categoría son “nfs” (Network File System), o “ssh”.
- milestone: Tal como en los viejos sistemas SVR4 teníamos “run levels”, en OpenSolaris tenemos “milestones”. Por lo tanto, esta categoría hará referencia al nivel de ejecución que el sistema operativo tendrá, y a los servicios dependientes que deberán encontrarse en estado de ejecución para considerar que ese “milestone” se ha alcanzado. Para verlo más claramente, un “milestone” podría ser “multi-user”, o “single-user”, por sólo citar un par de ejemplos.
- platform: Esta categoría hace referencia a servicios que sean específicos al hardware con el cual se está trabajando.
- site: Hacen referencia a la organización del sitio en el cual se esté trabajando. Esta categoría tiene toda la pinta de ser un placeholder, dado que al menos al día d ela fecha no encuentro ninguno que se lance desde ella.
- description: Tal como se podrán imaginar, es una descripción del servicio. Ni más ni menos.
- instance: Existen en OpenSolaris (así como en cualquier sistema operativo) servicios que podrán encontrarse en ejecución más de una vez, por ejemplo para entregar algo a más de un cliente. En casos como éste podremos encontrar diferentes instancias de un servicio ejecutándose al mismo tiempo.

Luego de haber enloquecido con toda esta nomenclatura, vamos a las arenas, y nos ponemos a ver en un simple gráfico cada uno de estos campos:

En muchos casos veremos que la “location” se obvia, por lo que el servicio presentado podría ser listado sencillamente como “svc:/network/dns/client:default”.

Isla de los Estados

Como era de esperarse, los servicios podrán tener diferentes estados, dependiendo de si se han lanzado, si están bajos, si han fallado, etc.
A continuación, un resumen de los estados posibles de un servicio:

- uninitialized: Este estado aparece cuando el proceso “svc.startd” aún no ha realizado ninguna acción sobre él. Cuando el sistema está booteando, por ejemplo, se podrían ver servicios en este estado.
- disabled: El administrador del sistema ha deshabilitado este servicio por algún motivo. Mientras que el estado sea éste, aún con un rebooteo continuará sin levantar.
- offline: El servicio se encuentra habilitado por el administrador del sistema, pero aún no se ha lanzado, de seguro por estar a la espera de una dependencia que debe ser satisfecha para su correcto funcionamiento. Más adelante veremos cómo se pueden declarar las dependencias para que sean revisadas por un servicio previo a su lanzamiento.
- online: Éste es el estado de felicidad absoluta del administrador de sistemas. Su salario ha quedado justificado por el resto del año. El servicio se ha lanzado, así como todas sus dependencias, y está funcionando. La casa está en orden, y…
- degraded: El servicio se encuentra online, y funcionando, pero con un nivel de performance degradado. Es el momento de tomar el toro por las astas, leer el log de ese servicio en particular, o ejecutar, como veremos más adelante “svcs –xv” para comprender el motivo por el cual ese servicio se encuentra en ese estado.
- maintenance: Es éste y no otro el estado por el cual se consume café entre los sysadmines. Algo ha logrado bajar nuestro servicio, y es nuestra misión como mega-plus-super-expertos en el área analizarlo y repararlo en forma adecuada. Pensabas que todo iba a ser mágico…pobre iluso…

Cuando un servicio aparece con el estado “maintenance”, debemos hurgar en sus fosas nasales hasta encontrar qué causa su malfuncionamiento. Para eso, encontraremos los correspondientes logs en “/var/svc/log”. Cada archivo se corresponde con un servicio en particular. Cada nombre de archivo comenzará con su “functional category” (por ejemplo, “network”), continuará con su “description” (por ejemplo, “ssh”), y finalizará con su “instance”, seguido de la palabra “log” (por ejemplo, “default.log”). El archivo de log correspondiente al servicio de ssh sería, entonces, “/var/svc/log/network-ssh:default.log”. No dolió tanto, ¿o sí?

Comandos azules

OpenSolaris nos entrega una nueva serie de comandos para gestionar los servicios del sistema. Y ellos, como en los casos anteriores, siguen los mismos estándares de las demás novedades de este sistema operativo: son pocos, y muy sencillos de aprender y utilizar.
En este caso, utilizaremos en general, y salvo grandes problemas, sólo cuatro comandos: svcs, svcprop, svcadm y svccfg. Sencillo, ¿no?
Veamos para qué sirve cada uno de estos comandos:

- svcs: Entrega información relativa al estado, dependencia, instancias y diagnóstico de procesos. Si nos encontramos que un determinado servicio no parece estar funcionando, utilizaríamos este comando para verificarlo. Veamos algunos ejemplos:
Este comando sólo nos muestra los servicios que se encuentran en ejecución:

root@server:~# svcs more
STATE STIME FMRI
legacy_run 17:44:25 lrc:/etc/rc2_d/S20sysetup
legacy_run 17:44:25 lrc:/etc/rc2_d/S47pppd
legacy_run 17:44:25 lrc:/etc/rc2_d/S72autoinstall
legacy_run 17:44:25 lrc:/etc/rc2_d/S73cachefs_daemon
legacy_run 17:44:25 lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run 17:44:25 lrc:/etc/rc2_d/S89PRESERVE
legacy_run 17:44:26 lrc:/etc/rc2_d/S98deallocate
online 17:43:35 svc:/system/svc/restarter:default
online 17:43:37 svc:/network/loopback:default
…

El siguiente nos mostrará todos los servicios declarados, estén o no en ejecución:

root@server:~# svcs -a more
STATE STIME FMRI
legacy_run 17:44:25 lrc:/etc/rc2_d/S20sysetup
legacy_run 17:44:25 lrc:/etc/rc2_d/S47pppd
legacy_run 17:44:25 lrc:/etc/rc2_d/S72autoinstall
legacy_run 17:44:25 lrc:/etc/rc2_d/S73cachefs_daemon
legacy_run 17:44:25 lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run 17:44:25 lrc:/etc/rc2_d/S89PRESERVE
legacy_run 17:44:26 lrc:/etc/rc2_d/S98deallocate
disabled 17:43:35 svc:/network/physical:default
disabled 17:43:35 svc:/system/device/mpxio-upgrade:default
disabled 17:43:36 svc:/system/svc/global:default
…

Y este último, los servicios que están marcados con problemas:

root@server:~# svcs –xv

- svcadm: Habilita, deshabilita, relanza y administra diferentes instancias de servicios. Si por ejemplo queremos bajar un servicio, o relanzarlo en forma manual, sería éste el comando que podríamos utilizar. Este comando posee varios argumentos que manejarán su comportamiento, dentro de los cuales encontramos:
- enable: Habilita la instancia del servicio especificado. Esto pondrá al servicio como “online”, lo lanzará, y mantendrá su estado entre booteos.
- disable: Ídem caso anterior, pero lo deshabilita.
- restart: Relanza un servicio siempre y cuando el mismo se encuentre en estado “online” o “degraded”.
- refresh: Verifica la nueva configuración del servicio, y solicita a “svc.startd” que la modifique, mientras se encuentra en ejecución.
- clear: Cuando un servicio se fue a estado “maintenance” por algún motivo, y habiendo solucionado la causa raíz del problema, ejecutaremos “svcadm” con este argumento para que limpie dicho estado, y lo relance.
- mark: Si una instancia de un servicio se encuentra en estado “maintenance”, este argumento pone en el mismo modo a todos los servicios e instancias especificados. Si la instancia se encuentra en modo “degraded”, hace lo mismo pero colocándolos en modo “degraded”.

Analicemos un ejemplo con el servidor web Apache:
Primero, verificamos si Apache se encuentra en funcionamiento:

root@server:~# svcs apache22
STATE STIME FMRI
online 17:44:27 svc:/network/http:apache22

Viendo que su estado es “online”, procederemos a bajarlo con el comando:

root@server:~# svcadm disable apache22
root@server:~# svcs apache22
STATE STIME FMRI
disabled 0:20:36 svc:/network/http:apache22

Ahora, procederemos a subirlo con el comando:

root@server:~# svcadm enable apache22
root@server:~# svcs apache22
STATE STIME FMRI
online 0:41:09 svc:/network/http:apache22

Lo pondremos en modo “maintenance”:

root@server:~# svcadm mark maintenance apache22
root@server:~# svcs apache22
STATE STIME FMRI
maintenance 0:52:57 svc:/network/http:apache22

Y finalmente lo pondremos nuevamente en modo online:

root@server:~# svcadm clear apache22
root@server:~# svcs apache22
STATE STIME FMRI
online 0:54:18 svc:/network/http:apache22

Nótese que en todos los casos anteriores, no se ha utilizado el FMRI completo para invocar al servicio, sino sólo una parte significativa de su nombre. Esto es posible siempre que no haya más de una instancia de ese servicio´y que no exista otro servicio con la misma “description”, pero con alguno de los demás componentes de su FMRI diferentes. Algo tenía que ser simple, después de todo…

- svccfg: Configura los parámetros necesarios en cada servicio. También permite importar y exportar configuraciones de servicios. Si es invocado sin ningún FMRI, abre un prompt propio, para trabajar con los diferentes servicios del sistema. Por ejemplo, si se tiene un servicio web basado en Apache, y se desea cambiar el puerto 80 por otro, sería éste el comando a utilizar.
- svcprop: Entrega un detalle de los permisos y propiedades de un servicio. Si un determinado usuario no puede lanzar un servicio, podríamos comenzar analizando si tiene los permisos necesarios a través de este comando.

Hablemos de milestones

Cuando obtuvimos el listado de servicios, encontramos varios que tenían entre sus functional categories la palabra "milestone". Un servicio tipo "milestone" forma parte de un grupo que permite, tal como antes ocurría con los niveles de ejecución de un sistema operativo *nix, llevar el sistema a un determinado nivel de ejecución.
Por lo tanto, y como es lógico, encontraremos una determinada analogía entre los niveles de ejecución de los sistemas *nix basados en scripts rc*, y OpenSolaris.
Veamos cuáles son estas correspondencias:

- : En SMF existe un nivel de ejecución que no existe en otros sistemas operativos, donde sólo el kernel se encuentra en funcionamiento. El nombre de este milestone será "none".
s ó S: Lo que en otros sistemas operativos se consideraba el nivel "single-user", en OpenSolaris recibe, justamente, este nombre: milestone "single-user". Si ejecutamos:

root@server:/etc# svcs -a grep milestone grep single-user

...la salida será:

online 23:48:29 svc:/milestone/single-user:default

2: El nivel "2" es considerado como el multiusuario sin recursos compartidos. Si bien se permite el ingreso por telnet, o ssh, no debieran existir, en este nivel, filesystems exportados mediante NFS, o cualquier otro sistema. En OpenSolaris, este milestone se denomina "multiuser". Tal como en el caso anterior, ejecutaremos:

root@server:/etc# svcs -a grep milestone grep multi-user

...y la salida será:

online 23:48:49 svc:/milestone/multi-user:default

3: El nivel "3" es el multiuser pero a diferencia del anterior, con recursos compartidos. El equivalente en OpenSolaris es el milestone "multi-user-server".
5: Es el equivalente a mencionar todos los niveles anteriores.

Por lo tanto, si debiéramos dejar nuestro sistema operativo en un nivel diferente al que actualmente posee, debemos utilizar, como en todos los casos anteriores, el comando svcadm:

root@server:/etc# svcadm milestone single-user

El comando anterior lo llevaría a nivel single user.
El conjunto de programas que se ejecutarán en cada nivel se puede explorar de una manera muy sencilla, por ejemplo, revisando el archivo /var/svc/manifest/milestone/single-user.xml.

Conclusión

Hemos analizado cómo funcionan los servicios en OpenSolaris, ahora es momento de crear los nuestros propios para los sistemas que implementemos.
Al principio puede ser medio complicado, pero con el tiempo veremos que estos extraños comandos nuevos se nos volverán parte de nuestro día a día.

Software e ideología

2010-05-13T22:04:00.003-03:00

Hace algunos días grabamos, como siempre hacemos con otros amigos y colaboradores de la revista Tuxinfo, uno de nuestros podcasts. Como siempre, duró algo más de dos horas, que se tradujeron en algo así como una hora y cuarenta minutos luego de editado y recortado.
Entre los temas que tratamos estuvo el de una distribución de GNU/Linux compilada por un grupo de ideología socialista, y que conserva según ellos esta ideología en sus líneas de código. Se presentó un nuevo término, el de software comunitario, a diferencia del que usamos comúnmente, que es software libre.
Ahora bien, en un primer momento, y como análisis urgente, nos viene a la cabeza la idea de considerar este concepto como algo extraño, dado que no entendemos cómo una distribución se pueda considerar socialista, o de cualquier otra facción política.
Cuando pienso en política, recuerdo una charla con un viejo amigo, estudiante él de Filosofía y Letras, que me decía "políticos somos todos, vivimos en una polis en el sentido ámplio de la palabra...ahora bien, representantes políticos son unos pocos agraciados por nuestra confianza a la hora de sufragar". Me gusta y siempre me gustó el juego de romper con las estructuras mentales que uno tiene desde chico, y este amigo es un especialista en eso. Adoro esa actitud casi futbolística de enfrentar todo y plantearse la veracidad o no de cada cosa en teoría ya aprendida.
Si sigo estos conceptos, y me considero porlítico por vivir en la polis, y con eso quiero decir absorber lo que la polis ha determinado para mí, aún cuando me la replantee contínuamente, tengo que pensar que mi código también debiera llevar, embebido, un concepto o una ideología política que, al menos en forma subyacente, demostraría su orígen ideológico.
Pero todos sabemos que eso no es así. En general vamos a programar aunque más no sea un script en base al manual que hemos leído, el apunte que hemos encontrado, o como pudimos. Entonces, no podemos considerar que la ideología es el elemento subyacente en nuestro código. ¿Qué lo es?
Siguiendo con el mismo regimen de razonamiento, lo que haría que una determinada ideología se manifieste en este tipo de productos (seamos sinceros, estamos hablando, al menos en el podcast, de productos de software libre) entonces no es el código en sí mismo, sino la forma en la cual nosotros nos movemos en torno a él.
El compartirlo es una muestra de nuestra ideología. Tal como lo es el hecho de prestar un libro o una prenda a un amigo. ¿Lo es realmente?
¿Cuál es la ideología que nos dice que es mejor compartir para que todos podamos gozar de lo mismo, y cuál la que nos dice lo contrario?
Si tenemos en cuenta a Eric Hoff (muchos me odiarán por citarlo, y otros me amarán. Yo nunca perdoné que acepte un premio de las manos manchadas con sangre, es decir de Ronald Reagan), el socialismo sostiene una tendencia a plantearse lo establecido, y a intentar modificarlo para beneficiar a las clases populares, evitando la pérdida de gobernabilidad del estado por exceso en el poder de las corporaciones, los terratenientes, y demás predadores. La derecha, en cambio, apuntaría a no modificar prerrogativas de poder basado en el capital concentrado, en la raza, la religión, y demás bellezas creadas por el hombre para dividir y mejorar el nivel de vida de unos pocos a costilla de unos cuantos más.
Si seguimos estos conceptos, el proveer a las personas de herramientas libres que pueden utilizar sin pertenecer a una clase tal que las pueda pagar nos podría acercar a la izquierda. Remarco que no estoy hablando del código en sí mismo, sino de lo que con él hacemos, y cómo lo hacemos.
Pero entonces...si somos usuarios de software privativo, y decidimos manejarnos con la tan conocida técnica de entregar nuestra copia al mundo para que la misma sea utilizada sin pagar legalmente una licencia, nos volveríamos izquierdistas, tanto por romper con un esquema de poder, como por hacer justamente en donde más le duele. Casi parece una de las banderas políticas de los partidos que se hacen llamar de izquierda en el país en el que vivo yo.
No quiero volverme un matemático del razonamiento, porque creo carecer del nivel suficiente para hacerlo, pero sí quiero remarcar esto: no depende, tal como antes lo vimos, del tipo de software que utilicemos, sino de lo que con él logramos en los demás, y cómo intentamos romper con las estructuras existentes cuando las mismas estén mirando a grupos diferentes de los populares, al menos pensando en el izquierdismo.
¿Cuál es la conclusión, entonces? ¿Podría ser un ser humano considerado un izquierdista del software si no existiera el software libre?

De acuerdo a lo que estuvimos viendo más arriba, tal parece que sí. Pero claro está, la utilización de esta lógica cuando se quiere aplicar a teorías políticas, a veces falla.

Bio (for OGB elections)

2010-03-08T01:02:00.002-03:00

Career:
- First career: Electronic Engineering.
- Second career: Information Systems Engineering.

Work experience:
- Sisteco (Wang in Argentina) as laboratory engineer.
- IBM (Andalucia, Spain) as field engineer for RS/6000, mainframes, AS/400 and other goodies.
- Sade, Engineering & Constructions (back to Argentina) as...some sort of servo-controlled systems engineer.
- Sisteco (yes, again!) as field engineer.
- Cidi.com Argentina (SunService in Argentina) as a field engineer.
- Banknet S.A. (Sun Microsystems Financial Vertical Market reseller) as IT Manager.
- Telefónica Moviles Argentina (now Movistar) as CTO.
- Oracle Argentina as Core Technologies Senior Consultant.
- Currently, at Verizon Business Argentina as Project Manager.

Other groups and affiliations:
- LUGAr (Linux User Group of Argentina), as founder and now...the oldest member! - more than 15 years working and having fun.
- Currently, at CaFeLUG (Capital Federal Linux Users Group), as founder and...oldest guy too (I feel OLD) - I cannot remember how much time...more than 10 years for sure.
- Currently, at AOSUG (Argentina OpenSolaris Users Group), as founder and actual leader for more than 4 years.
- Currently, Greek Tragedy workshops for 5 years.

Tech Talks:
- "PostgreSQL" at Palermo University.
- "MySQL Internals" at Belgrano University.
- "Glassfish" at La Plata National Engineering University.
- "OpenSolaris Virtualization" several times, at Buenos Aires University (Engineering), LUGFI (Linux Users Group - Engineering University).
- "Cloud Computing" several times, at Verizon Business Argentina.

Articles:
- Currently, and for 10 months, I write OpenSolaris articles for Tuxinfo magazine (www.tuxinfo.com.ar).
- Firewalls, for AULA Project (AULA = Classroom in Spanish).

Prizes:
- Siemens prize for the best electronics technician. But I was very young, now to repair my radio i driving me crazy...
- Performance prize at Telefónica because of the design and implementation of the Prepaid real time telecommunications system. My cell phone still works when he wants.
- A strange prize at Verizon Business for a series of Cloud Computing tech talks. Sorry, Larry...

Our future plans for 2010 (AOSUG):
- Participate in Flisol 2010 (Latinamerican Free Software Installation Festival, normally almost 300 people per city).
- Give tech talks at CaFeCONF (Open Source conference, typically more than 1500 people).
- Organize SFD'2010 as we did last year (more than 300 people last year only in Buenos Aires).
- Give tech talks as JRSL'2010 (Regional Free Software Annual Conference, normally more than 2500 people in two days).
- Help schools and universities to build their Open Source laboratories and classrooms.
- Continue having monthly meetings.
- Help the community grow, and grow, and grow. And have a lot of fun while learning, and teaching.

My other stuff:
- Love old movies, classic books, cinema, coffee.
- Collect clocks.
- TaeKwonDo (I'm II Dan now).

Collective Relationships
Collective type Collective Relationship
Community Group advocacy Leader
Electorate advocacy electorate Core Contributor
User Group aosug Leader
Community Group device_drivers Participant
Project es Participant
Community Group ha-clusters Participant
Community Group int_localization Participant
User Group neaosug Leader
Community Group pm Participant
Project portals Participant
Community Group sw-porters Participant
Project usecase Participant
Community Group zfs Participant

Configuración de IP estática con NWAM

2010-03-07T22:11:00.003-03:00

Hola!
En este artículo, hablaremos un poco sobre NWAM, una facilidad de OpenSolaris que configura las direcciones IP en forma automática.
La cuestión es que es muy sencillo que una máquina con OpenSolaris configure su interface de red mediante DHCP: no se debe hacer absolutamente nada!
Y cuando estamos configurando un servidor, y queremos que use una dirección IP estática? Ahí la cosa se complica un poco más, pero tampoco demasiado.
Una nota de color es que la mayor parte de los comandos que ejecutaremos, y para los archivos que modificaremos, necesitaremos permisos de root, por lo que bien podemos hacer "pfexec" antes de cada comando, bien podemos ejecutar "su -", y listo.
La cuestión es que vamos a ver si tenemos NWAM funcionando mediante el comando:

Sun Microsystems Inc. SunOS 5.11 snv_111b November 2008
root@ns1:~# svcs nwam
STATE STIME FMRI
online 23:07:18 svc:/network/physical:nwam

Vemos que, efectivamente, nuestra máquina está usando NWAM. Si nos entregara un valor "disabled", entonces debiéramos ejecutar un comando para ver si el servicio "default" está levantado:

root@ns1:~# svcs physical
STATE STIME FMRI
online 23:07:16 svc:/network/physical:default
disabled 23:07:18 svc:/network/physical:nwam

...bajar "physical:default":

root@ns1:~# svcadm disable svc:/network/physical:default

...y subir "physical:nwam"

root@ns1:~# svcadm enable nwam

Bien, ahora, a modificar archivos, así tenemos nuestra dirección IP estática, y configuramos todos los demás parámetros (DNS, default router, y name services) de nuestra interface de red.

Suponemos que nuestra interface de red será la e1000g0, tendrá la dirección 10.100.100.19, su máscara de red es la 255.255.255.0, su default router es el 10.100.100.1, y que sus DNS's son los 200.42.0.111, 200.42.97.111, y 200.42.0.110.

Los pasos a seguir serán:

a) Modificar el archivo /etc/nwam/llp:
Originalmente, su contenido es:
e1000g0 dhcp
Y se modifica para que quede:
e1000g0 static 10.100.100.19/24

b) Relanzar el NWAM:
root@ns1:~# svcadm restart nwam

c) Configurar el default router:
root@ns1:~# route -p add default 10.100.100.1

d) Configurar los DNS servers:
Modificar el archivo /etc/resolv.conf para que su contenido sea:
nameserver 200.42.0.111
nameserver 200.42.97.111
nameserver 200.42.0.110

e) Configurar los name services para que DNS sea uno de ellos:
Modificar el archivo /etc/nsswitch.conf para que su entrada hosts sea:
hosts: files dns

f) Si queremos, relanzamos el NWAM, y si queremos ver que todo funciona perfecto, rebooteamos el sistema, y nos fijamos si todo quedó bien usando los comandos:
1) ifconfig e1000g0
2) netstat -nr
3) ping a una dirección DNS conocida, y que responda el ping.

Listo! Todo funciona ya! Happy networking!

Servidor hogareño - versión OpenSolaris

2009-07-08T23:01:00.019-03:00

En este artículo veremos cómo hacer un servidor hogareño con OpenSolaris.
La versión que se está utilizando en esta oportunidad, es la 2009.06, desde su repositorio de release (no se está usando la versión dev).

Servidor DHCP

Una vez instalado el sistema operativo, y ejecutado como root un "pkg refresh --full", procederemos a la instalación y configuración del servidor DHCP.
Para ello, ejecutamos:

# pkg install SUNWdhcs SUNWdhcm

Con eso quedan instalados tanto los binarios del dhcp server, como los del DHCP Manager, una herramienta gráfica para administrar DHCP basada en Java, que nunca pensé que podría haber sido tan útil sino hasta que tuve que usarla.
Para configurar el dhcp server, tengamos en cuenta algunos detalles importantes:
a) Basaré mi configuración en archivos, no en NIS, ni en DNS.
b) Guardaré dicha configuración en el directorio /var/dhcp
c) El rango de IP's de mi red estará en 10.100.100.0.
d) La dirección IP de mi servidor será 10.100.100.2
e) Necesito que uno de mis equipos obtenga siempre la misma dirección IP, que será la 10.100.100.4. La MAC address de este equipo será la 00:16:D4:0E:1C:A9.
f) Mi default router será el 10.100.100.1, y mis DNS's serán 200.42.0.111, 200.42.97.111, 200.42.0.110 y 200.42.97.110.
Con estos datos en mente, vamos a comenzar con la configuración del servidor DHCP.

1) Configurar archivos como fuente de información, /var/dhcp como directorio para poder los archivos de configuración, DNS servers, dominio, y lease time:

# dhcpconfig -D -r SUNWfiles -p /var/dhcp -a 200.42.0.111,200.42.97.111,200.42.0.110,200.42.97.110 -d hecsa.com.ar -h files -l 86400

2) Configurar la red, su máscara, y el default gateway:

# dhcpconfig -N 10.100.100.0 -m 255.255.255.0 -t 10.100.100.1

3) Configurar una dirección para un equipo en base a su MAC address, agregándolo al macro generado para la red 10.100.100.0:

# pntadm -A 10.100.100.4 -c "Battlelloyd" -f MANUAL -i 010016D40E1CA9 -m 10.100.100.0 -y 10.100.100.0

Nótese que en este caso, se ha agregado un "01" a la MAC address que queremos configurar.

4) Agregar direcciones IP al pool disponible para otros equipos, éstos dinámicos:

# pntadm -A 10.100.100.200 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.201 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.202 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.203 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.204 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.205 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.206 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.207 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.208 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.209 -m 10.100.100.0 -y 10.100.100.0
# pntadm -A 10.100.100.210 -m 10.100.100.0 -y 10.100.100.0

5) Reiniciamos el servidor DHCP para que tome los cambios realizados:

# svcadm restart dhcp-server

6) Abrimos el DHCP Manager, y configuramos los DNS's en forma correcta (no sé si esto es un bug, o algo que no configuré bien, pero debí hacerlo para que todo funcione):

$ pfexec dhcpmgr (nótese que en este caso no uso la cuenta de root, sino que hago un pfexec, para poder levantar la interface gráfica java)

La interface gráfica que levanto es la siguiente:

Ahora selecciono la solapa de Macros, dentro de la que elijo el Macro 10.100.100.0.
Ahora, del menú superior (Edit), selecciono la opción "Properties", y agrego la siguiente:
Option Name: DNSserv
Option Value: 200.42.0.111 200.42.97.111 200.42.0.110 200.42.97.110
Presiono el botón "Add", y lo confirmo con "OK".
Finalmente, reinicio los servicios de DHCP con el mismo DHCP manager, seleccionando, el menú superior, "Service", luego "Restart".
Salgo del DHCP Manager sencillamente con "File" - "Exit".

Listo! Ya ha quedado configurado el servidor DHCP, y está alimentando de direcciones IP al resto de mi red.

Servidor SAMBA

La siguiente fase de esta implementación es la de permitir que el sistema pueda compartir archivos con los demás clientes de la red. Para eso, elegimos el servidor SAMBA.
Para instalarlo, ejecutamos:

# pkg install SUNWsmba

Para los que están acostumbrados a GNU/Linux, algunos tips sobre los lugares donde encontraremos los archivos más comunes:
a) Archivos de configuración:
1) smb.conf: /etc/sfw/smb.conf
b) Archivos de log:
1) Por una cuestión de simplicidad, decidí poner los archivos de log en /var/log/samba, por lo cual debí generar ese directorio. Por omisión no lo genera, lógico!

Configuración del archivo smb.conf:

[global]
workgroup = HECSAGRP
netbios name = DSHECSA1
server string = %h server
obey pam restrictions = Yes
passdb backend = tdbsam
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
log level = 2
log file = /var/log/samba/log.%m
max log size = 1000
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = /usr/sbin/useradd -d /var/lib/nobody -s /bin/false -M %u
logon script = %U.cmd
domain logons = Yes
os level = 65
domain master = Yes
dns proxy = No
wins support = Yes
ldap ssl = no
panic action = /usr/share/samba/panic-action %d
invalid users = bin, daemon, sys, man, postfix, mail, ftp
admin users = @wheel smbadmin
interfaces = 10.100.100.2 127.0.0.1
hosts deny = 10.100.100.1/255.255.255.255
hosts allow = 10.100.100.0/255.255.255.0

[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0700
directory mask = 0700
browseable = No
dont descend = profile

[netlogon]
comment = Network Logon Service
path = /export/home/samba/netlogon
share modes = No

[printers]
comment = All Printers
path = /tmp
create mask = 0700
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers

[hecsarchive]
comment = Directorio Archivos de HeCSa
path = /archivos/hecsa
valid users = @interno, root
read only = No
create mask = 0770
directory mask = 0770
browseable = No

Agrego el usuario hecsa, mi usuario dentro de la red SAMBA, ya existente en OpenSolaris a nivel Unix:

# smbpasswd -a hecsa
New SMB password:
Retype new SMB password:
Added user hecsa.

Genero el path donde los usuarios del grupo "interno" podrán depositar sus archivos. Entre estos usuarios, tendré al usuario "hecsa":

# mkdir -p /archivos/hecsa
# groupadd interno

Ahora, modifico la línea correspondiente al archivo "/etc/group" para que el usuario "hecsa" forme parte de él:

interno::100:hecsa

Cambio los permisos del directorio a compartir:

# chgrp -R interno /archivos/hecsa

Para probar si todo funcionó bien, relanzo los procesos de Samba:

# svcadm restart samba

Desde mi PC intento levantar el path //10.100.100.2/hesarchive, y funciona perfectamente! Eso quiere decir que mi servidor de archivos ha quedado funcionando.
Victoria!

Mirror Debian en OpenSolaris

2009-04-15T22:28:00.003-03:00

Este artículo tiene por objeto explicar la forma en la cual configuré un servidor de paquetes Debian y Ubuntu dentro de un equipo que tiene instalado OpenSolaris 2008.11.
La idea detrás de esto es poder servir las actualizaciones de equipos Debian y Ubuntu desde OpenSolaris, entregándoles un mirror que funcione perfectamente.
Para poder hacerlo, utilicé el sistema "apt-mirror", y por lo tanto, partí de una de mis máquinas, que lo tenía instalado, para poder recrear la configuración sobre OpenSolaris.
Manos a la obra!

Primer desafío: comando apt-mirror

El primer paso, es generar el grupo y usuario necesarios para poder utilizar el comando de la misma forma que se hace en cualquier máquina con Ubuntu o Debian.

root:~# groupadd apt-mirror

UX: groupadd: apt-mirror name too long.

UX: groupadd: apt-mirror name should be all lower case or numeric.

root:~# grep apt-mirror /etc/group apt-mirror::100:

root:~# useradd -g apt-mirror -d /var/spool/apt-mirror -m apt-mirror

UX: useradd: apt-mirror name too long.

UX: useradd: apt-mirror name should be all lower case or numeric.

80 blocks

root:~# passwd apt-mirror

New Password:

Re-enter new Password:

passwd: password successfully changed for apt-mirror

Luego, generamos los directorios necesarios para que se ejecute el comando apt-mirror, y guarde los paquetes espejados. Tenemos especial consideración, aquí, de los permisos y propietarios necesarios.

root:~# mkdir /etc/apt

root:~# chmod 755 /etc/apt
root:~# su - apt-mirror

Sun Microsystems Inc.

SunOS 5.11 snv_101b November 2008

apt-mirror:/var/spool/apt-mirror$ mkdir mirror skel var

Luego, copiamos el archivo mirror.list del servidor linux utilizado como modelo de origen dentro del directorio recién creado, /etc/apt.
Recordemos configurar sus entradas para que sepa de dónde se deberá espejar el conjunto de paquetes, así como qué arquitecturas se deberán espejar (x86, amd64, etc.)

root:~# cd /etc/apt

root:/etc/apt# scp hecsa@linux:/etc/apt/mirror.list .

The authenticity of host 'linux (linux)' can't be established. RSA key fingerprint is dc:78:ff:1d:17:c6:50:52:d2:80:87:15:49:03:f0:a8. Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'linux' (RSA) to the list of known hosts.

hecsa@linux's password:

mirror.list 100% |*****************************| 2457 00:00

root:/etc/apt# ls -ltr

total 3

-rw-r--r-- 1 root root 2457 2009-04-15 21:58 mirror.list

El contenido de este script será del siguiente estilo, por ejemplo:

set nthreads 20

set _tilde 0

deb http://debian.logiclinux.com/debian stable main contrib non-free

deb-amd64 http://debian.logiclinux.com/debian stable main contrib non-free

deb-src http://debian.logiclinux.com/debian stable main contrib non-free

Ahora, copiamos el script perl apt-mirror dentro de /usr/bin.

root:/etc/apt# cd /usr/bin

root:/usr/bin# scp hecsa@linux:/usr/bin/apt-mirror .

hecsa@linux's password:

apt-mirror 100% |*****************************| 16424 00:00

root:/usr/bin# ls -las apt-mirror

17 -rwxr-xr-x 1 root root 16424 2009-04-15 22:01 apt-mirror

Finalmente, intentaremos ejecutarlo con el siguiente comando (necesitaremos una buena cantidad de espacio en disco si queremos que baje todos los paquetes):

root:/usr/bin# su - apt-mirror -c apt-mirror

Podemos jugar un poco con la lista de paquetes que se bajarán, por ejemplo, agregando las siguientes entradas en el archivo /etc/apt/mirror.list, para que soporte aparte de Debian, Ubuntu:

deb http://espelhos.edugraf.ufsc.br/ubuntu/ jaunty universe main multiverse restricted

deb-amd64 http://espelhos.edugraf.ufsc.br/ubuntu/ jaunty universe main multiverse restricted

Segundo desafío: Configurar el web server

Ahora, deberemos hacer que nuestro web server entregue estos paquetes a los futuros clientes.

Para ello, lo único que debemos hacer es generar dos links simbólicos, uno para Ubuntu, y otro para Debian, de la siguiente forma:

root:/etc/apt# ln -s /var/spool/apt-mirror/mirror/debian.logiclinux.com/debian /var/apache2/2.2/htdocs/debian

root:/usr/bin# ln -s /var/spool/apt-mirror/mirror/espelhos.edugraf.ufsc.br/ubuntu /var/apache2/2.2/htdocs/ubuntu

Y con lo anterior, ya estamos listos para servir a clientes Ubuntu y Debian en su proceso de instalación, cosa que se hizo en el Flisol 2009, en forma exitosa, siendo ésta la primera vez que un servidor OpenSolaris está implementado para instalar clientes de otras arquitecturas, al menos hasta donde yo sé.

Saludos, hasta la próxima!!!

HeCSa

Ver DivX, DVD, y escuchar mp3 en OpenSolaris 2008.11

2009-02-25T21:16:00.004-02:00

De seguro muchos se habrán preguntado por qué no pueden ni ver DVD's, ni Divx, ni escuchar mp3 en su nueva y bonita instalación de OpenSolaris.
Bueno, la respuesta es bien simple: porque no tienen los codecs necesarios, dado que algunos de ellos son propietarios, y no es política de la gente de OpenSolaris, entre los cuales me incluyo, poner cosas privativas en la distribución.
Si bien Sun tiene sus intereses en él, se intenta mantener OpenSolaris lo más opensource que se pueda, a pesar de haber aún porciones que tienen una licencia medio cerradita, que digamos...
Pero bueno, lo que se debe hacer en el caso de querer utilizar estos formatos multimedia, es lo siguiente:

a) Agregar el correspondiente repositorio:
# pkg set-authority -O http://ips.homeunix.com:10000 ips.homeunix.com

b) Actualizar la lista de paquetes:
# pkg refresh --full

c) Instalar los paquetes:
# pkg install MBLgst-plugin-mp3 MBLgst-plugin-dvd MBLgst-plugin-ffmpeg

d) Abrí tu programa de música favorito, y ponete a escuchar. Please, elegí algo bueno. Soda Stereo, Metallica, o Pink Floyd podrían ser ejemplos, si te sirve de guía.
Saludos!

HeCSa.

Implementación de Big Brother en ambientes heterogéneos

2009-02-08T17:23:00.008-02:00

El presente artículo tiene por objeto explicar la forma en la cual se ha implementado la solución de monitoreo y alarma "Big Brother", versión gratuita, en un ambiente heterogéneo, específicamente uno que posee servidores GNU/Linux (Red Hat y Ubuntu), Solaris y Windows 2003 Enterprise Server.

El sistema Big Brother utiliza, para poder funcionar, ciertos conceptos, a saber:

Un BBDISPLAY es un servidor que contendrá la capa de visualización del sistema de monitoreo Big Brother.
Un BBPAGER es un servidor que podría tener un sistema de conexión a un SMS Center para enviar en forma directa mensajes a quienes se determine.
Lo más común del mundo es que el servidor de Big Brother, es decir, el que recibe las alertas de todos los clientes, así como el que ejecuta el web server que muestra el resultado de los monitoreos, sea el mismísimo BBDISPLAY y BBPAGER.
Cada servidor cliente debe ejecutar el paquete cliente de Big Brother para poder recolectar métricas, y reportarlas al servidor de Big Brother.

Ahora que tenemos estos conceptos en nuestra mente, pasemos a poner manos a la obra.

Instalación del servidor de Big Brother (y el primer cliente!)

Para instalar el servidor de Big Brother ante todo se debe bajar el archivo correspondiente al código fuente desde la dirección http://www.bb4.org.
En nuestro caso, el servidor de Big Brother será un sistema con Red Hat Linux ES 4.3 instalado, que a los efectos de esta práctica, llamaremos "bbserver".
El paquete que hemos bajado se llama "bb-1.9i.tar.gz", y contiene dentro de sí dos paquetes, uno que es el servidor en sí mismo ("BBSVR-bb1.9i-btf.tar"), y otro que es el cliente ("BBCLT-bbc1.9i-btf.tar"). Podremos ver estos dos paquetes luego de descomprimirlo con el comando "tar zxvf bb-1.9i.tar.gz".
Ahora, llega la hora de instalar el servidor.
Por cuestiones de seguridad, lo mejor es generar un grupo denominado "bb", y un usuario denominado "bb", para que estos monitores no tengan, bajo ningún punto de vista, que acceder archivos utilizando el superusuario ("root").
Los comandos para generar el grupo y el usuario son los siguientes:

[root@bbserver opt]# groupadd bb
[root@bbserver opt]# useradd -d /home/bb -m -g bb -c "Big Brother" -s /bin/bash bb
[root@bbserver opt]# passwd bb (ingresar una contraseña)

Una vez generado el usuario y el grupo, procederemos a la instalación de los paquetes descomprimidos, considerando que en este equipo, para poder monitorearlo, se deberán instalar los dos, tanto el servidor como el cliente de Big Brother.
Para la instalación del servidor, ejecutamos los siguientes comandos:

[root@bbserver opt]# cd /opt
[root@bbserver opt]# tar zxvf bb-1.9i.tar.gz
[root@bbserver opt]# tar xvf BBSVR-bb1.9i-btf.tar
[root@bbserver opt]# chown -R bb:bb bb1.9i-btf (o el directorio que haya generado el paquete del servidor)
[root@bbserver opt]# su - bb
[bb@bbserver bb]$ mkdir ~/public_html/cgi-bin
[bb@bbserver bb]$ cd /opt/bb1.9i-btf/install
[bb@bbserver install]$ ./bbconfig redhat
Responder a las preguntas que aquí nos hace el instalador con lo siguiente:

El usuario de Big Brother será "bb".
La máquina será un BBDISPLAY.
La máquina será un BBPAGER (aunque todavía no lo usemos, dejémoslo configurado).
El URL base será "/bb" porque luego del http://servidor.web, queremos que sea accedido el monitoreo por medio de ese directorio. El URL al que accederemos será http://servidor.web/bb.
El directorio para cgi-bin será "/home/bb/public_html/cgi-bin", dado que lo creamos en un paso anterior a tales fines.
El usuario que levanta el web server será "apache", a menos que en nuestro caso sea otro, como ser "nobody" (si no lo sabemos, verifiquemos los procesos que están en ejecución correspondientes al web server, con "ps aux | grep http", por ejemplo).

[bb@bbserver install]$ cd ../src
[bb@bbserver src]$ make
[bb@bbserver src]$ make install
[bb@bbserver src]$ exit
[root@bbserver opt]# cd /var/www/html (o el directorio que se haya configurado como base de nuestro web server).
[root@bbserver html]# ln -s /opt/bb1.9i-btf/www bb
[root@bbserver html]# cd /etc/cron.daily
[root@bbserver cron.daily]# vi logrotate (esto es para quitar un bug conocido que impide al usuario "bb" la lectura del archivo "messages", generando, por lo tanto, un falso alerta).
El archivo deberá quedar así:
#!/bin/sh
/usr/sbin/logrotate /etc/logrotate.conf
/bin/chmod 644 /var/log/messages # Esta línea se agregó para solucionar este bug.
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

Con estos pasos, quedará implementado el servidor Big Brother.

Para instalar el cliente del propio servidor, tendremos que seguir los siguientes pasos:

[root@bbserver html]# cd /opt
[root@bbserver opt]# tar xvf BBCLT-bbc1.9i-btf.tar
[root@bbserver opt]# chown -R bb:bb bbc1.9i-btf
[root@bbserver opt]# su - bb
[bb@bbserver bb]$ cd /opt/bbc1.9i-btf/install
[bb@bbserver install]$ ./bbconfig redhat (responder a todas las preguntas que nos hace el instalador. Generalmente el default está bien).
[bb@bbserver install]$ cd ../src
[bb@bbserver src]$ make
[bb@bbserver src]$ make install

Con estos pasos, queda instalado el cliente de Big Brother.

Ahora, sólo nos falta configurar un archivo tanto del lado del servidor como del cliente, que especifica cuáles serán los clientes a monitorear, así como qué opciones de monitoreo se le dará a cada uno de ellos.
El archivo es el "/opt/bb1.9i-btf/etc/bb-hosts" del lado del servidor, y "/opt/bbc1.9i-btf/etc/bb-hosts" del lado del cliente.
Es importante notar que ambos archivos, así como los de todos los clientes, debieran de quedar con la misma configuración (al menos eso solicita el manual de Big Brother).
En dicho archivo, se deberán comentar todas las entradas que estén descomentadas, dejando sólo las siguientes:

group Servidores Productivos
192.9.200.5 bbserver.dominio.com.ar # BBPAGER BBNET BBDISPLAY

Ahora sí, se podrá ejecutar el servidor con el comando (siempre como el usuario "bb") "/opt/bb1.9i-btf/runbb.sh", y el cliente con el comando "/opt/bbc1.9i-btf/runbb.sh".
Accederemos a la información generada luego de por lo menos diez minutos, a través del URL http://servidor.web/bb .

Implementación de un cliente Solaris 10

Para implementar un cliente Solaris 10 tendremos que generar, tal como lo hemos hecho antes, un grupo y un usuario específicos para Big Brother.
Para ello, seguimos estas secuencias de comandos:

root@solaris # groupadd bb
root@solaris # useradd -g bb -d /export/home/bb -m -c "Big Brother" -s /usr/bin/bash bb
64 blocks
root@solaris # passwd bb
New Password:
Re-enter new Password:
passwd: password successfully changed for bb
root@solaris # cd /opt
root@solaris # tar xvf BBCLT-bbc1.9i-btf.tar
root@solaris # chown -R bb:bb bbc1*
root@solaris # su - bb
bb@solaris $ cd /opt/bbc1.9i-btf/src
bb@solaris $ vi Makefile (debemos hacer esto para que no tome como comando "make" otro que no sea el "gmake", entonces cambiamos el contenido de la línea que dice "MAKE = make", por "MAKE = gmake").
bb@solaris $ cd ../install
bb@solaris $ ./bbconfig solaris
(Responder a las preguntas aceptando la licencia, el usuario "bb", y el uso de FQDN (Fully Qualified Domain Names).
bb@solaris $ cd /opt/bbc1.9i-btf/src
bb@solaris $ make
bb@solaris $ make install
bb@solaris $ vi /opt/bbc1.9i-btf/etc/bb-hosts

Dejemos el contenido de este archivo de la siguiente forma:

192.9.200.5 bbserver.dominio.com.ar # BBPAGER BBNET BBDISPLAY
192.9.200.109 solaris.dominio.com.ar

bb@solaris $ cd /opt/bbc1.9i-btf
bb@solaris $ ./runbb.sh

Ahora, en el sistema servidor de Big Brother, debemos agregar la siguiente entrada en "/opt/bb1.9i-btf/etc/bb-hosts":

[bb@bbserver bb]$ cd /opt/bb1.9i-btf/etc
[bb@bbserver etc]$ vi bb-hosts
Agregar la entrada:

192.9.200.109 solaris.dominio.com.ar

[bb@bbserver etc]$ cd ..
[bb@bbserver bb1.9i-btf]$ ./runbb.sh stop
[bb@bbserver bb1.9i-btf]$ ./runbb.sh
Starting Big Brother
Starting Big Brother Daemon (bbd)...
Starting Network tests (bb-network)...
Starting Display process (bb-display)...
Big Brother 1.9i started

Con estos pasos, quedó implementado el cliente Solaris 10 de Big Brother.

Instalación de un cliente Windows NT/2000/XP/2003 de Big Brother.

Antes que nada, se deberá descargar el archivo instalable de la misma dirección de donde hemos bajado el resto del software.
Luego, sencillamente se deberá hacer doble click en él para ejecutarlo.
Se deberá seguir el esquema "Enter-Enter-Enter-Acepto la licencia-Enter-Instalar-etc." típico en los ejecutables Windows.
Una vez instalado, se abrirá ante nosotros una pantalla con el título "Big Brother Client Configuration Editor".
Posicionémonos en el campo BBDISPLAY hosts, y agreguemos al bbserver, específicamente su dirección IP, en él. Luego presionemos "Add". En el caso de aparecer otra dirección en la sección inferior, seleccionarla del menú desplegable, y presionar "Del".
Hacer lo mismo con el campo BBPAGER.
Presionar el botón "Save", y luego el "Start", para finalmente llegar al "Quit".
Con esos pasos, queda impementado el cliente Windows NT/2000/XP/2003 de Big Brother.

TROUBLESHOOTING: Bueno, en todo artículo hay una sección de este estilo.

Un problema que es más que típico en el sistema Big Brother es que, luego de implementar un cliente NT, algo quede mal configurado, y en particular, que eso sea ni más ni menos que el hostname del sistema Windows NT a monitorear.
Para solucionar este tema, y evitar así el efecto "eternamente púrpura", algún alma caritativa generó el comendo "bbrm".
Este comando nos permitirá eliminar de la configuración del servidor de Big Brother un equipo que ya no se quiere monitorear.
Se ejecuta, sencillamente, lo siguiente, desde el directorio de binarios de Big Brother: ./bbrm equipo
Veremos un mensaje que nos indica que ese servicio ha sido eliminado, y listo. En el próximo monitoreo, habrá desaparecido.

Error al instalar OpenSolaris 2008.11 - Panic - Dump - Reboot

2009-01-14T21:12:00.002-02:00

Luego de haber fracturado mi disco rígido, tuve que reinstalar todo lo que en él se encontraba.
Por suerte el último backup era más o menos reciente, así que sólo tuve que instalar los paquetes que ya tenía, y restaurar la información.
Algo me llamó bastante la atención, y es que al momento de instalar OpenSolaris 2008.11, desde el LiveCD original, se generaba un stack trace, un dump que terminaba con un mensaje de "panic", para finalmente rebootear mi máquina.
Cuando digo "mi máquina", me refiero a una HP Pavilion DV5000, con un procesador dual core T2400, 1 GB de RAM, y ahora sí, un disco SATA de 320 GB.
Aún no pude solucionar este tema al 100%, logré el workaround (no es realmente un workaround, porque no me funciona el audio), que fue agregar, en la línea del archivo /rpool/boot/grub/menu.lst, el flag "-B disable-audiohd=true", es decir, quedó así:
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS -B disable-audiohd=true
Reboteé, y por lo menos, levantó bien.

Actualizaste tu OpenSolaris y no te funcionan las zonas?

2008-11-22T00:38:00.011-02:00

Resulta que si una persona realiza una serie de comandos normales en su maquinilla OpenSolaris, y resulta que de ellos se actualiza la versión a algo superior a snv_98, se encontrará con que no podrá seguir utilizando el mismo procedimiento que antes para generar una zona porque se encontrará con el error:

Error: no zonepath dataset.

ó

Error: unable to determine global zone boot environment.

Qué hacemos entonces?
Pues bien, el primer paso es entender que hay que generar un dataset diferente del que ahora tenemos, para entonces sí generar la zona como antes.
Pero antes de eso, tal parece que a nueva versión de ZFS ha cambiado, por lo que habrá que actualizarla, por un lado, y generar un nuevo BE (boot environment) que contiene un UUID que permite la generación de estas nuevas versiones de zonas.

Los primeros comandos, entonces, serán:

# zpool upgrade -a
# beadm create -a osol2008.11

(el primer comando actualiza a la última versión los pool's ZFS, y el segundo, genera un nuevo boot environment que contendrá la llamada al famoso UUID, llamada osol2008.11).

Luego, no olvidemos instalar un paquetito, que de seguro por omisión no está instalado, que es el correspondiente a rcap (veamos que en la zona del ejemplo, estamos usando resource capping, y por eso necesitamos de este paquete):

# pkg install SUNWrcap

Entonces, ejecutaremos:

# zfs create rpool/zones
# zfs set mountpoint=/zones rpool/zones
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 14.0G 16.3G 65.5K /rpool
rpool/ROOT 8.74G 16.3G 18K /rpool/ROOT
rpool/ROOT/opensolaris-6 8.74G 16.3G 7.17G legacy
rpool/ROOT/opensolaris-6/opt 1.57G 16.3G 1.57G /opt
rpool/export 5.25G 16.3G 19K /export
rpool/export/home 5.25G 16.3G 5.25G /export/home
rpool/zones 18K 16.3G 18K /zones

Con estos bonitos comandos lo que hice fue generar un dataset denominado "rpool/zones", que monté en /zones. Nada más que eso.
Luego, configuraré mi zonita como lo hacía antes de este tema:

# zonecfg -z osol1
osol1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:osol1> create
zonecfg:osol1> set zonepath=/zones/osol1
zonecfg:osol1> set autoboot=false
zonecfg:osol1> add capped-memory
zonecfg:osol1:capped-memory> set physical=128m
zonecfg:osol1:capped-memory> set swap=256m
zonecfg:osol1:capped-memory> end
zonecfg:osol1> add net
zonecfg:osol1:net> set address=192.9.200.105/24
zonecfg:osol1:net> set physical=iprb0
zonecfg:osol1:net> end
zonecfg:osol1> commit
zonecfg:osol1> exit
root@invid:~# zoneadm -z osol1 install
A ZFS file system has been created for this zone.
Authority: Using http://pkg.opensolaris.org:80/.
Image: Preparing at /zones/osol1/root ... done.
Cache: Using /var/pkg/download.
Installing: (output follows)
...

Ahora bien, luego de haber creado las nuevas zonas, en algún momento querrás actualizar el sistema operativo mediante un "pkg refresh --full" y "pkg image-update".
Cuando quise hacer esto, me encontré con que no pude, debido a que me aparecieron los mensajes:

pkg: unable to create BE None
pkg: image-update cannot be done on live image

Entonces, destruí las zonas generadas mediante el comando "zonecfg -z osol1 delete -F", y "zonecfg -z osol2 delete -F". Sí, tenía dos zonas funcionando.
Luego de esto, borré los nuevos datasets que generé en los pasos anteriores:

# umount -f /zones/osol1
# umount -f /zones/osol2
# rm -rf /zones/osol1
# rm -rf /zones/osol2
# zfs umount -f /zones
# zfs destroy -r rpool/zones

Ahora sí, a actualizar el sistema operativo, como de costumbre:

# pkg image-update

Y ahora todo funciona! Ya tengo el S.O. actualizado, como lo esperaba.
Ah! olvidaba algo! Puede que en el primer intento luego de haber tenido un par de errores de booteo de la zona aparezca un error del estilo:

zone 'osol1': Error: error mounting zone root dataset.
zone 'osol1':
zoneadm: zone 'osol1': call to zoneadmd failed

...y eso es porque antes de este intento de booteo, el sistema ya había montado un filesystem en particular, que es el siguiente:

rpool/zones/osol1/ROOT/zbe
98518633 237113 98281520 1% /zones/osol1/root

En este caso, sencillamente lo desmontamos, y luego reintentamos el booteo, y listo!

Como ven, soluciones sencillas.
Saludos cordiales,

HeCSa.

Servidor de correo con Ubuntu 8.04

2008-05-28T21:25:00.002-03:00

En este artículo abordaremos la implementación de un servidor de correo utilizando solamente software libre.

Su sistema operativo será Ubuntu 8.04, y el MTA (Mail Transfer Agent) será Postfix.

Fase I: Instalación del sistema operativo

Bueno, como ya se debe estar pensando, esta fase no presenta ningún problema en sí mismo, dado que la instalación que se seguirá es la del sistema operativo Ubuntu 8.04 Server por omisión.

Comienza con el booteo, se selecciona el lenguaje (yo elegí "English"), luego por la zona en la cual me encuentro (yo elegí "other", y luego "South America - Argentina"), luego por el teclado, donde seguí todas las instrucciones hasta que detectó que el teclado de seguro estaba configurado como "latam".

Configuró sólo la tarjeta de red, y por un error de planificación, levantó su dirección IP desde un servidor de DHCP. Eso no hace sino más interesante la tarea, dado que también debo explicar aquí cómo hacer para que se fije una dirección IP. El nombre que elegí para el servidor, en un esfuerzo de imaginación, fue "mailer".

Luego configuró el reloj, particioné el disco (en la sección "Partition Disks" elegí "Manual", luego generé tres particiones, la /dev/sda1, de sólo 150 MB, para /boot, la /dev/sda2, de 1.5 GB, para swap, y la /dev/sda3, del resto, para /), instaló todos los paquetes básicos del servidor, lo cual me llevó menos de 15 minutos, y me solicitó la creación de un nuevo usuario, que será luego el que hará "sudo" cuando sea necesario.

Luego de eso, le avisé que no estaba usando ningún proxy, se realizó la configuración automática de "apt", me pidió que seleccione qué paquetes de software quería instalar, en base a la función del equipo (DNS, LAMP, Mail, OpenSSH, PostgreSQL, Print ó Samba server, de las cuales no seleccioné ninguna, dado que me ocuparé luego de esa instalación de una forma más personalizada y selectiva de paquetes), comenzó la instalación de software (Select and Install software), realizó automáticamente la instalación del GRUB, y finalizó la instalación, con reboot.

En el primer booteo parecía que el servidor estaba colgado, dado que tardó un poco más de lo normal para un equipo de sus características (casi 15 segundos en dar alguna señal de vida), pero a continuación levantó perfectamente.

El nombre del equipo es, sencillamente, "mailer".

Al realizar un "ifconfig -a" encontré que la dirección IP, efectivamente, coincidía con una del rango del DHCP Server que tengo conectado a la red, por lo que ahora comienza la parte donde configuramos la dirección IP final de la tarjeta de red.

Ingresé como el usuario que había configurado, y cambié mi personalidad (no es recomendable trabajar como root siempre) haciendo "sudo /bin/bash". Me pidió la contraseña mía propia, y pude obtener el tan amado prompt "#". Todas las siguientes tareas serán realizadas mediante la cuenta del usuario generado, y el "sudo /bin/bash".

Edité el archivo "/etc/network/interfaces" para que su contenido sea:

auto lo
iface lo inet loopback

iface eth0 inet static
address 192.9.200.20
netmask 255.255.255.0
gateway 192.9.200.1

network 192.9.200.0
broadcast 192.9.200.255

auto eth0

...dado que la dirección de red que le quiero dar es la 192.9.200.200, suponiendo que esa es una dirección pública válida (obviamente, quien alguna vez tuvo algún contacto con Internet desde el punto de vista serio, sabe que no lo es).

Edité el archivo "/etc/resolv.conf", agregándole los que son mis dos servidores de DNS:

nameserver 200.42.0.108
nameserver 200.42.0.109
domain hecsa.com.ar

Ahora, para verificar que todo quedaba como es debido, relancé los procesos de red mediante "/etc/init.d/networking restart"

El siguiente paso, dentro de lo que es el sistema operativo en sí mismo, consistió en instalarle el paquete OpenSSH Server, lo cual hice como siempre, con "apt-get install openssh-server"

Fase II: Vamos por los paquetes

Ahora, lo jugoso. Se viene la instalación del sistema de correo electrónico, se viene!!!

Vamos a comenzar instalando los paquetes que sean necesarios, y para eso, también como siempre, realizaremos las actualizaciones que correspondan.

Para eso, la receta de cocina adecuada es ejecutar "apt-get update", y "apt-get upgrade", aceptando las actualizaciones que nos proponga nuestro amigo "mailer". Se recomienda, luego de esto, realizar un nuevo reboot, sólo por si las actualizaciones han sido profundas, y sus efectos, luego de un "reboot", son requeridos.

Ahora, con los últims paquetes instalados, procedemos a instalar los que serán necesarios para nuestro servidor de correo electrónico, a través de los siguientes comandos:

# apt-get install postfix courier-imap courier-pop mailx

Pocos paquetes, no? Bueno, esto nos va a dejar bajando cerca de 10 MB de paquetes, lo cual nos permite tomar algún café en el medio de la implementación, que nunca viene mal.

Cuando instalemos el paquete postfix, se nos preguntará qué tipo de sistema queremos, a lo cual responderemos que el mismo será un "Internet Site". Acto seguido, nos pedirá que agreguemos un valor para el dominio, considerando que los mails salientes que no lo posean lo terminarán teniendo como agregado. Si bien en este caso la opción por default es el hostname completo, se deberá colocar el nombre del dominio del cual saldrán los mensajes.

Cuando instalemos los paquetes courier-imap y courier-pop, veremos que se nos pregunta si queremos generar algunos directorios del tipo Maildir para algunos usuarios, a lo cual responderemos que no.

Fase III: A configurar todo

Por suerte, la simplicidad de estos paquetes nos llevarán a no tener que configurar demasiadas cosas cuando lo que queremos es un servidor de correo para un solo dominio, por lo que en general, veremos que los pasos son pocos, y sencillos.

El primer archivo que tocaremos será el "/etc/postfix/main.cf". Allí configuraremos lo siguiente:

smtpd_banner = Cualquiera (OpenCualquiera)
biff = no

append_dot_mydomain = no

readme_directory = no

smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

myhostname = mailer.dominio.com.ar
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = dominio.com.ar, mailer.dominio.com.ar, localhost.dominio.com.ar, localhost
relayhost =
mynetworks = 192.9.200.0/24, 192.168.100.0/24, 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 # Redes desde las cuales permito que se envíen mails.
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
home_mailbox = Maildir/ # Este es el formato del mail, maildir, y en cada home directory habra un subdirectorio llamado Maildir, que contendra cur, tmp y new.
mailbox_command =

Por ahora, no tengo que tocar nada más, ya que el mismo courier-imap y courier-pop se han ocupado de configurarse como es debido.

Fase IV: Seguridad

Ahora bien, con la configuración anterior, tendremos un excelente servidor de correo, pero será un blanco perfecto para cuanto spammer haya dando vueltas, por lo que se recomienda seguir estos pasos para asegurar que no terminaremos en una blacklist de spam.

Fase IV-A: Shorewall

Como este servidor tiene más de una tarjeta de red (véase que hay dos en la declaración de mail.cf, una con IP 192.9.200.x y la otra con 192.168.100.x), se ha configurado la misma desde el archivo "/etc/network/interfaces":

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.9.200.20
        netmask 255.255.255.0
        network 192.9.200.0
        broadcast 192.9.200.255
        gateway 192.9.200.1
        dns-nameservers 200.42.0.108 200.42.0.109
        dns-search dominio.com.ar

auto eth1
iface eth1 inet static
        address 192.168.100.250
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255

Ahora, comenzaremos a realizar la configuración del paquete shorewall. Primero, lo instalamos con el comando "apt-get install shorewall shorewall-doc".

Una vez que tengamos estos dos paquetes instalados, procederemos a configurar sus archivos, de la siguiente manera:

cp /usr/share/doc/shorewall-common/default-config/interfaces /etc/shorewall/ vi /etc/shorewall/interfaces

En este archivo agregaremos las definiciones de nuestras dos tarjetas de red:

net eth0 detect dhcp,tcpflags,logmartians,nosmurfs

net eth1 detect dhcp,tcpflags,logmartians,nosmurfs

Luego:

cp /usr/share/doc/shorewall-common/default-config/zones /etc/shorewall/ vi /etc/shorewall/zones

Aquí configuraremos las dos zonas que estaremos utilizando, es decir, la de la red, y la del firewall en sí mismo:

net ipv4

Luego:

cp /usr/share/doc/shorewall-common/default-config/hosts /etc/shorewall/

Luego:

cp /usr/share/doc/shorewall-common/default-config/policy /etc/shorewall/ vi /etc/shorewall/policy

Aquí agregaremos las políticas que deseamos:

$FW net ACCEPT

net $FW DROP info

net all DROP info

# Esta politica debe estar al final

all all REJECT info

Luego:

cp /usr/share/doc/shorewall-common/default-config/routestopped /etc/shorewall/ vi /etc/shorewall/routestopped

Y agregamos:

eth0 0.0.0.0 routeback

eth1 0.0.0.0 routeback

Luego:

cp /usr/share/doc/shorewall-common/default-config/rules /etc/shorewall/ vi /etc/shorewall/rules

Y agregamos:

SSH/ACCEPT net $FW

Ping/ACCEPT net $FW

# Permit all ICMP traffic FROM the firewall TO the net zone

ACCEPT $FW net icmp

# mail lines

SMTP/ACCEPT net $FW

SMTPS/ACCEPT net $FW

Submission/ACCEPT net $FW

IMAP/ACCEPT net $FW

IMAPS/ACCEPT net $FW

POP3/ACCEPT net $FW

#web

Web/ACCEPT net $FW

Chequearemos que todo esté correctamente configurado mediante:

shorewall check

Editamos "vi /etc/default/shorewall" y modificamos el valor de "startup" para que esté en 1:

startup=1

Ahora, si queremos, podemos realizar un reboot y ver cómo levantan todos los servicios implementados, inclusive los del firewall (shorewall - realmente iptables)

Fase IV-B: Fail2ban

Si bien en este mismo blog habrán visto algunos detalles sobre cómo implementar estar herramienta, les cuento que la misma ha cambiado desde la publicación de este artículo, por lo que ahora veremos la versión que se puede implementar desde un servidor Ubuntu 8.04 (fail2ban 0.8.2-2).

Comenzamos instalando un paquete como lo hacemos siempre, mediante la ejecución de "apt-get install fail2ban".

Una vez instalado, sólo les recomiendo que modifiquen el archivo "/etc/fail2ban/jail.conf" de la siguiente forma:

destemail = yo@dominio2.com.ar

De esa manera, cada vez que algún caco de la información y el ancho de banda quiera ingresar y falle por más de cierta cantidad de veces, le llegará un mail a esta dirección, aparte de deshabilitar a la dirección IP de origen.

Recordemos que siempre luego de hacer cualquier modificación a los archivos del fail2ban, tendremos que relanzar sus procesos mediante "/etc/init.d/fail2ban stop" y "/etc/init.d/fail2ban start".

Fase IV-C: Postgrey

Ahora, uno de los platos fuertes de esta noche, aparte de todo lo que vimos antes. Vamos a implementar el sistema postgrey, que no es ni más ni menos que un greylisting para el servidor de correos Postfix.

El principio del proceso es el mismo de siempre, debemos instalarlo con el comando "apt-get install postgrey".

Luego, tendremos que modificar el archivo "/etc/postfix/main.cf" para que comience a utilizar este sistema. Le agregaremos las siguientes líneas:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        check_policy_service inet:127.0.0.1:60000

Y finalmente relanzamos los procesos del postfix para que se tomen los cambios ("/etc/init.d/postfix stop" y "/etc/init.d/postfix start").

Servidor Hogareño - Versión GNU/Linux

2008-05-25T00:44:00.002-03:00

Este artículo tendrá por objeto dar las explicaciones necesarias para poder montar un servidor hogareño basado en GNU/Linux. Los servicios que se pretenden brindar son: DHCP, PDC, FileServer, Proxy, y Filtrado de Páginas. Si hay tiempo, un servidor del tipo Portal estaría también muy bueno.

La versión de GNU/Linux elegida, en este momento, es la Ubuntu 8.04, que si bien ha demostrado que no es la más rápida, por lo menos está basada en paquetes .deb, verifica de una forma medianamente coherente dependencias, y permite su actualización con un grado bastante sencillo de tareas.

El primer punto ha sido instalar la distribución por default, generando una partición de 8 GBpara el swap, y de 130 GB para /.

Lo ideal no es dejar todo el contenido del primer disco sin dividir filesystems, pero en este caso, como el servidor tendrá características hogareñas, no hace falta más.

Cayendo sin red

Mi motherboard es un ASUS P5GC-MX/1333, que tiene una tarjeta de red Attansic L2, por supuesto, como me gustan los desafíos, no soportada directamente por Ubuntu 8.04. Y digo no soportada directamente, porque si bien el driver aparece dentro de los existentes en esta versión, sencillamente no funcionan con este motherboard. Los módulos de esta tarjeta de red aparecen como cargados al ejecutar un "lspci", pero no funcionan, lo cual nos lleva, ante todo, a tener que buscar un nuevo driver, que deberá funcionar mejor que éste.

Efectivamente, con el motherboard me llegó un CD con drivers. Entre ellos, encontré que aparecía un directorio llamado "LinuxDrivers". Excelente, me dije, y sin pensarlo, seguí el procedimiento necesario para compilarlos. Nada más inútil, porque llegué a un mensaje de error que me decía que no tenía el directorio /usr/src/linux-headers-2.6.24-16-generic. No hay problema, utilicé el ingenio, y saqué de internet, en otra máquina, desde el sitio packages.ubuntu.com, esos paquetes y sus dependencias. Los grabé en un memory stick, y los instalé en el equipo.

Para poder compilar lo que necesitaba, sin saber si era o no necesario, pero sabiendo que en algún momento lo sería, instalé, desde el CD de Ubuntu, el paquete build-essential.

Pero tampoco funcionó, dado que me apareció, al ejecutar "make", un mensaje haciendo referencias a problemas de CFLAGS, requiriendo que se modifiquen los parámetros para que se utilicen EXTRA_CFLAGS. Cuando estaba a punto de darme por vencido, y comenzar con alguna otra distro, que me diera más y mejores drivers (según tengo entendido, ya hay varias que así lo hacen), encontré un código fuente dedicado a esta tarjeta, que se encuentra en http://people.redhat.com/csnook/atl2/atl2-2.0.4.tar.bz2 . Lo bajé, lo compilé, y el módulo atl2.ko resultante, lo copié a /lib/modules/2.6.24-16-generic/ubuntu/net/atl2/atl2.ko.

Rebooteé el equipo, y la configuración de red comenzó a funcionar. La familia, contenta. Ahora puedo hacer un "apt-get update", y que funcione. Lo sé, no me olvidé de comentar las entradas del CD de Ubuntu en "/etc/apt/sources.list".

Conexión vía terminal y VNC

Una de las primeras cosas que necesité, fue el servidor OpenSSH, dado que me resultaría más cómodo trabajar con el servidor de esta manera, en forma remota. Para ello, instalé el paquete openssh-server con el comando "apt-get install openssh-server". El sistema bajó también el "libssl0.9.8.0.9.8g-4ubuntu", el "openssh-client", y el "openssh-blacklist". Luego de la instalación, y sólo para ver si todo levantaba correctamente desde el principio, rebotee el sistema.

Una cosa que me encantó de este motherboard es que un reboot dura menos de 30 segundos. Increíble.

Inmediatamente después, me pude conectar desde otros equipos sin problemas:

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/
hecsa@dshecsa01:~$

Excelente, el primer paso estaba dado!

Ahora, vamos por la conexión vía VNC. Como es sabido, el paquete a instalar es el vncserver.

Al hacer un "apt-cache search vncserver", encontré que uno de los listados era el "vnc4server". Lo instalé con el comando "apt-get install vnc4server", y posteriormente lo inicié con el comando "vncserver". Así de sencillo.

Ahora bien, la primera imágen es que el entorno en sí se veía bastante básico, por lo que descomenté las siguientes dos líneas en el archivo $HOME/.vnc/xstartup, para que levante por VNC un entorno más completo, como el que tengo en la consola del equipo:

unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc

Claro que lo que el sistema quiere es levantar el TWM, que no tenía instalado, por lo cual ejecuté "apt-get install twm". Reinicé el servidor con los comandos "vncserver -kill :1", y "vncserver", y todo quedó de maravillas.

Compartiendo los archivos

Por supuesto, lo que debía hacer ahora era instalar el servidor Samba, y configurarlo para que pueda funcionar como un PDC.

Primer paso, instalar el paquete samba: "apt-get install samba".

El paquete aparentemente, se instaló correctamente, pero arrojó unos mensajes extraños, que luego analizaré (Veremos el resultado de este análisis en el apéndice dedicado a tales fines):

tdbsam_open: Converting version 0 database to version 3.
account_policy_get: tdb_fetch_uint32 failed for field 1 (min password length), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 2 (password history), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 3 (user must logon to change password), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 4 (maximum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 5 (minimum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 6 (lockout duration), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 7 (reset count minutes), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 8 (bad lockout attempt), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 9 (disconnect time), returning 0
account_policy_get: tdb_fetch_uint32 failed for field 10 (refuse machine password change), returning 0

Ahora, pasaremos a la configuración, que calculo que no será una tarea menor. Veamos cómo transformamos este servidor en un Samba PDC.

Para eso, lo primero que hago es generar un archivo "/etc/samba/smb.conf" como el siguiente:

[global]
workgroup = GRUPETE
netbios name = SERVER1
server string = %h server
obey pam restrictions = Yes
passdb backend = tdbsam
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
log level = 2
log file = /var/log/samba/log.%m
max log size = 1000
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=8192 SO_RCVBUF=8192
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = /usr/sbin/useradd -d /var/lib/nobody -s /bin/false -M %u
logon script = %U.cmd
domain logons = Yes
os level = 65
domain master = Yes
dns proxy = No
wins support = Yes
ldap ssl = no
panic action = /usr/share/samba/panic-action %d
invalid users = bin, daemon, sys, man, postfix, mail, ftp
admin users = @wheel

[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0700
directory mask = 0700
browseable = No
dont descend = profile

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
share modes = No

[printers]
comment = All Printers
path = /tmp
create mask = 0700
printable = Yes
browseable = No

[print$]
comment = Printer Drivers
path = /var/lib/samba/printers

[archive]
comment = Directorio Archivos
path = /archivos
valid users = @interno, root
read only = No
create mask = 0770
directory mask = 0770
browseable = No

Ahora, a generar los usuarios. Comienzo por el mío, así que como sé que está generado en el sistema GNU/Linux, ejecuto "smbpasswd -a hecsa".

Inmediatamente, o mejor dicho, luego de esperar unos minutos, pude levantar desde una máquina separada los directorios compartidos mediante el protocolo de Samba. Otro éxito, y ya van varios!

Dame una dirección, por favor

Ahora, le llegaba el turno al servidor DHCP, que tantas alegrías nos da siempre.

Lo primer, es instalar el paquete que nos dará este servicio. Al hacer un "apt-cache search dhcpd" encontré a mi viejo amigo y aliado "dhcp3-server", que como siempre, instalé con el comando "apt-get install dhcp3-server".

Lo interesante es que luego de instalarlo, aparecen estos mensajes:

* Starting DHCP server dhcpd3 [fail]
invoke-rc.d: initscript dhcp3-server, action "start" failed.

Pero al mirar archivos como el "/var/log/messages", o el "/var/log/daemon.log", no encontramos más que mensajes de subida el dhcpd, lo cual desconcierta bastante.

Para evitar seguir hurgando en detalles extravagantes, sencillamente dejé el archivo "/etc/dhcp3/dhcpd.conf" de la siguiente forma:

option domain-name "hecsa.com.ar";
option domain-name-servers 200.42.0.108, 200.42.0.109;

default-lease-time 600;
max-lease-time 7200;

subnet 192.9.200.0 netmask 255.255.255.0 {
range 192.9.200.220 192.9.200.230;
option routers 192.9.200.1;
option domain-name-servers 200.42.0.108, 200.42.0.109;
authoritative;
}

host hecsadv {
hardware ethernet 00:13:02:61:23:C4;
fixed-address 192.9.200.142;
}

A que no se imaginan qué pasó cuando levantó de nuevo el servicio dhcpd, con los comandos "/etc/init.d/dhcp3-server stop" y "/etc/init.d/dhcp3-server start"? Mírenlo ustedes mismos:

root@dshecsa01:/etc# /etc/init.d/dhcp3-server stop
* Stopping DHCP server dhcpd3 [fail]
root@dshecsa01:/etc# /etc/init.d/dhcp3-server start
* Starting DHCP server dhcpd3 [ OK ]

Sí, así es...quedó funcionando. Ya tenemos servidor de direcciones, y hasta una dirección fijada para una de las máquinas de la red. Qué tal, eh?

Servidor Proxy

Nada más sencillo que instalar un servidor proxy en GNU/Linux, y ni que hablar sobre Ubuntu.
Lo único que tendremos que hacer es ejecutar "apt-get install squid".
Ahora viene la parte de la configuración, que si bien tampoco es complicada, merece que se explique de forma adecuada para evitar problemas.
Lo primero que tendremos que hacer es ingresar al directorio /etc/squid, y copiar el archivo instalado por omisión, squid.conf, como squid.conf.original, o lo que querramos que sea.
Ahora, lo editaremos, y le cambiaremos las siguientes líneas:

visible_hostname dshecsa01
acl mi_red src 192.9.200.0/24
http_access allow mi_red

Ahora, bajamos y subimos el squid con el set de comandos "/etc/init.d/squid stop" y "/etc/init.d/squid start", y todo queda funcionando.

Apéndices

Solución de backup

Para realizar backups, y dado que remarco la característica de "hogareño" de este servidor, nada como un buen DVD-RW.

Para poder usarlo con GNU/Linux, nada como implementar el excelente programa K3B, realmente una versión mejorada de cualquier programa de grabación de CD/DVD que haya visto.

Como siempre, lo instalo con el comando "apt-get install k3b". Pero como el K3B requiere de otros programas para funcionar perfectamente, ejecuto también "apt-get install normalize-audio", "apt-get install sox", "apt-get install transcode", "apt-get install vcdimager", y me faltaría algo que levante el eMovix, pero por ahora no lo encuentro. Con lo que tengo, ya podré realizar la mayor parte de todas las cosas que generalmente hago con un programa como el K3B.

Diario íntimo de mis experiencias con OpenSolaris en una HP DV5000

2008-05-09T01:15:00.022-03:00

Prefacio
Veremos que la primer instalación de OpenSolaris corresponderá a la 2008.05, que es la que me ha llegado a mis manos en este momento. A medida que vaya actualizando el sistema operativo, encontraremos en el futuro modificaciones a este blog basándonos en estas novedades.
Bueno, gracias a la llegada a mis manos del tan esperado Indiana, decidí instalarlo en mi notebook HP DV5000, desde la cual estoy escribiendo este artículo (eso quiere decir que instalarlo pude, y fue bien sencillo).
Símplemente, reventé mis particiones de GNU/Linux (no lloren, tengo otra de mis máquinas que tiene instalada la versión que hasta ahora veo con mayor performance del mercado, que es Arch Linux), y decidí comenzar con el proceso de booteo desde el LiveCD, para luego darle un click en el ícono de "Install OpenSolaris".
Todo se instaló perfectamente. Pude setear los locales en español, que en este momento ya me parece una rareza para lo que venía siendo OpenSolaris (o mejor dicho, antes de OSOL 2008.05, lo que era el SXDE y el SXCE), y tengo un bonito escritorio con el Compiz instalado, gracias a haber habilitado los efectos de escritorio. Para esto, sólo hice un click derecho sobre el escritorio, y cuando abrí el selector de fondos de escritorio, elegí habilitar los efectos. Nada más, y absolutamente igual a cualquier escritorio que haya instalado en esta misma máquina.
Lo que vengo probando de funciones de Internet realmente funcionan muy bien, está bastante aceitado, y es hasta más rápido que en el entorno Ubuntu que tenía antes (eso no es raro, Ubuntu ya hace tiempo que tardaba en bootear hasta más que Windoze eXtraPollution SystemPanic 2, que no es poco).
Ahora bien, comienzo este blog para registrar las vueltas que tendré que dar hasta tanto tenga configurado todo de la forma que debiera.

Sonamos
Comienzo por el sonido, que por lo visto, es parte de las figuritas difíciles de OpenSolaris.
Mi tarjeta de sonido, según la salida del comando /usr/X11/bin/scanpci es:

-bash-3.2# ./scanpci | grep -i audio
Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller

Los primeros indicios que encontré en la red son poco alentadores, así que me tendré que poner a ver cómo hago que esta belleza me entregue el primer mp3 como la gente.

Así es que me bajé de la página del proyecto OSS el paquetito famoso, y lo instalé:

-bash-3.2# pkgadd -d oss-solaris-v4.0-1015-i386.pkg

The following packages are available:
1 oss Open Sound System
(i386) v4.0-1015

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]:

Processing package instance from
...
Using as the package base directory.
## Processing package information.
## Processing system information.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

This package contains scripts which will be executed with super-user
permission during the process of installing this package.

Do you want to continue with the installation of [y,n,?] y

Installing Open Sound System as

## Installing part 1 of 1.
...
[ verifying class ]
[ verifying class ]
## Executing postinstall script.
Setting up Open Sound System....please wait
add_drv -m '* 0666 root sys' osscore
add_drv -m '* 0666 root sys' -i '"pci8086,27d8"' hdaudio
add_drv -m '* 0666 root sys' -i '"usbif,class1"' ossusb
add_drv -m '* 0666 root sys' vmix
add_drv -m '* 0666 root sys' sadasupport

Open Sound System installation complete

You can use the osstest command to test audio playback in your system.

It may be necessary to reboot the system before all devices get properly
detected by the system.

Installation of was successful.
Rebooteé, ejecuté "osstest", saqué los pedazos de parlante que quedaron pegados en las paredes, y seguí adelante con mi linda máquinita.
Ni hablar de la forma en la que mejoró el sonido cuando levanté el programa gráfico "ossxmix", y cambié, en el jack, la entrada de "mix" por "pcm1". Créanme, suena mejor, por lejos!!!

Samba de mi esperanza
Otra de las cosas que yo, exótico del arte informático quise hacer es montar un espacio compartido de un servidor Samba que tengo en mi casa. Claro, lo que pasa es que yo soy un extraño vicioso, y quiero cosas estrafalarias en mi máquina. Por eso no me funcionó de entrada. Acá les copio la salida inmoral al intentar montar el filesystem famoso:

-bash-3.2# mount -F smbfs -o username=hecsa,password=QueTeImportaPibe //192.9.200.2/hecsarchive /media/samba
mount_smbfs: service "svc:/network/smb/client:default" not enabled.

Divino, no? Claro, montar un filesystem Samba es algo que no es común que la gente haga, así que es muy lógico tener que habilitar un servicio, mandar un cohete a la luna y pensar en la fusión en frío para poder volver a hacer uso de este extraño feature.
Así que me cargué de paciencia, y ejecuté este comando:

-bash-3.2# svcadm enable -r smb/client
Luego de un mensaje que me decía que dependía de varios rezos para que funcione, pude montar mi filesystem, pero con otros flags, como podrán ver aquí:
-bash-3.2# mount -F smbfs //hecsa@192.9.200.2/hecsarchive /media/samba
Password:
-bash-3.2# df -k /media/samba
Filesystem kbytes used avail capacity Mounted on
//hecsa@192.9.200.2/hecsarchive
240362656 170983848 69378808 72% /media/samba

Bien! Primer prueba superada! Ya tengo mi filesystem Samba montado en mi máquina! Juro que mi emoción es sublime. Y casi no tuve que hacer nada.

No me gustaban los horarios de oficina
Bueno, ahora me digo: quiero editar un archivo de "oficina". Oh, sorpresa, en el menú de Oficina sólo tengo el Evince. Parece que en una oficina la gente sólo mira PDF's, por ejemplo.
Vamos, nomás. Instalemos el openoffice, a ver si podemos llegar a la victoria, y tener un sistema de escritorio funcionando como se debe.
Ejecuto los siguientes comandos:
(Para ver qué paquete instalar)

-bash-3.2# pkg search -s pkg.opensolaris.org openoffice
INDEX ACTION VALUE PACKAGE
basename dir opt/openoffice.org2.4/share/registry/modules/org/openoffice pkg:/openoffice@2.4.0-0.86
basename dir opt/openoffice.org2.4/share/registry/modules/org/openoffice pkg:/openoffice@2.4.0-0.86
basename dir opt/openoffice.org/share/registry/modules/org/openoffice pkg:/openoffice@0.5.11-0.79

(Y para instalarlo)

-bash-3.2# pkg install openoffice
DOWNLOAD PKGS FILES XFER (MB)
Completed 1/1 4220/4220 420.64/420.64

PHASE ACTIONS
Install Phase 4798/4798

Luego de un minuto, me aparecieron en el menú los íconos tan gloriosos de todos los productos incluídos en el OpenOffice, y la familia oficinista, contenta...

El compilado de este verano
Ahora bien, como de seguro voy a tener que usar el compilador C para poder hacer uso de cualquier driver que haya que compilar, me decido a buscarlo, simplemente con "which gcc". No está en el path, o directamente no está instalado.
Vamos:
(Para buscar el paquetito)

-bash-3.2# pkg search -s pkg.opensolaris.org gcc
INDEX ACTION VALUE PACKAGE
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.86
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.79
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.75
basename link usr/bin/gcc pkg:/SUNWgcc@3.4.3-0.86
(Y para instalar el bendito paquete)
(Me baja el SUNWgcc, SUNWbinutils, SUNWarc, y el SUNWhea)
-bash-3.2# pkg install SUNWgcc
DOWNLOAD PKGS FILES XFER (MB)
Completed 4/4 2035/2035 88.13/88.13

PHASE ACTIONS
Install Phase 2457/2457

Bien, ahora ya puedo hacer mi "Hola, mundo" sin problemas...bueno, casi...

Permiso, por favor!
Lo cierto es que para poder hacer muchas de las cosas que quiero hacer, necesitaría algo parecido al gtksu, lo cual no pido, por lo que ejecuto:
-bash-3.2# usermod -R root hecsa
UX: usermod: hecsa is currently logged in, some changes may not take effect until next login.
[ACTUALIZACIÓN] Luego de algunas actualizaciones, este efecto ya no aparece. El entorno se ha vuelto bastante dinámico. Creo que estoy viviendo el proceso de construcción de un S.O., pero esta vez, en serio.

Mi primera vez
Sin duda, tiene que tener un apartado especial el dedicado a la primera actualización. Lo intenté realizar desde la interface gráfica, y al menos al primer intento, no pude. La razón? No sé, la veremos luego.
Un delirio que cuando me fijo en el tamaño de lo que tenía que bajar de internet era ni más ni menos que 1900 MB!!!
Encima de eso, la interface sistemáticamente se colgó cuando llegaba a los 1000 MB, por lo que tuve que cerrar la interface gráfica, y volver a abrirla.
No sé qué problema tiene, pero cuatro pulgares para abajo al gestor de paquetes, justamente por haber hecho que baje ni más ni menos que 1 GB de información que luego no sirvió para nada.
Aparte, las descripciones de los upgrades son un chiste.
Me aparecieron sólo cuatro paquetes que actualizar, y con sus dependencias llegamos a ese tamaño abominable.
[ACTUALIZACIÓN] - Luego de determinados updates, las imágenes son más chicas, y el gestor de paquetes ha sido mejorado notablemente. Ahora puedo instalar paquetes desde allí, si bien mi naturaleza de antaño me hace usar CLI. Bien por los desarrolladores, que están haciendo las cosas como se debe!

The (wired) network is the computer
Bueno, le llegó la hora a la tarjeta de red WiFi.
La cuestión es sencilla: en esta maquinita, he instalado los sistemas operativos más estrafalarios que una mente enferma pueda concebir. Y no me refiero sólo a los compatibles con M$ o Linux.
Pero al intentar levantar la tarjeta de red WiFi, oh, sorpresa, ni siquiera se digna a encender su luz.
Al ejecutar un scanpci, como lo hice antes, encontré que la tarjeta es una:

pci bus 0x0006 cardnum 0x00 function 0x00: vendor 0x8086 device 0x4222
Intel Corporation PRO/Wireless 3945ABG Network Connection

Cómo hacemos para que esta verdadera belleza funcione?
Buscando en foros del más allá, encontré uno que mencionaba que era necesario instalar el driver wpi, y por eso ejecuté:

-bash-3.2# pkg search wpi
INDEX ACTION VALUE PACKAGE
basename file kernel/drv/wpi pkg:/SUNWwpi@0.5.11-0.86
driver_name driver wpi pkg:/SUNWwpi@0.5.11-0.86

...quería ver si había algo de ese estilo dando vueltas por ahí.
Pero la sorpresa la tuve cuando quise instalarlo, y me encontré con que ya estaba en el sistema:

-bash-3.2# pkg install SUNWwpi
Nothing to install in this image (is this package already installed?)

Entonces...qué le pasa a la niña?
Bueno, el primer lugar para buscar es en /var/log/messages. Lo que ahí encontré fue esto:

May 10 01:38:38 invid wpi: [ID 133862 kern.warning] WARNING: wpi_init(): timeout waiting for firmware init

Entonces, usamos la munición gruesa:
La salida del comando scanpci -v nos entrega:

pci bus 0x0006 cardnum 0x00 function 0x00: vendor 0x8086 device 0x4222
Intel Corporation PRO/Wireless 3945ABG Network Connection
CardVendor 0x103c card 0x135b (Hewlett-Packard Company, Card unknown)
STATUS 0x0010 COMMAND 0x0046
CLASS 0x02 0x80 0x00 REVISION 0x02
BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x10
BASE0 0xd2100000 addr 0xd2100000 MEM
MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x03

...y el comando prtconf -pv nos entrega:

Node 0x000017
assigned-addresses: 82060010.00000000.d2100000.00000000.00001000
reg: 00060000.00000000.00000000.00000000.00000000.02060010.00000000.00000000.00000000.00001000
compatible: 'pciex8086,4222.103c.135b.2' + 'pciex8086,4222.103c.135b' + 'pciex8086,4222.2' + 'pciex8086,4222' + 'pciexclass,028000' + 'pciexclass,0280' + 'pci8086,4222
.103c.135b.2' + 'pci8086,4222.103c.135b' + 'pci103c,135b' + 'pci8086,4222.2' + 'pci8086,4222' + 'pciclass,028000' + 'pciclass,0280'
model: 'Network controller'
power-consumption: 00000001.00000001
devsel-speed: 00000000
interrupts: 00000001
subsystem-vendor-id: 0000103c
subsystem-id: 0000135b
unit-address: '0'
class-code: 00028000
revision-id: 00000002
vendor-id: 00008086
device-id: 00004222
pcie-capid-pointer: 000000e0
pcie-capid-reg: 00000011
name: 'pci103c,135b'

Cómo sé que se trata de la tarjeta en cuestión, y no de la ethernet? Sencillo, porque en "model" no dice nada de ethernet.
Intenté, entonces, removiendo el driver con el comando "rem_drv wpi", y luego agregándolo de nuevo con "add_drv -i "pci8086,4222" wpi", pero no pasó nada...snif...
[ACTUALIZACIÓN] - Luego de pasar la versión snv_95, todo funciona perfectamente. Me conecto a redes WiFi como con cualquier otro S.O. Brillante!!! Luego de la snv_101a, hasta me aparece un bonito mensaje avisándome de cuanto elemento necesito para saber el estado de la red. Brillante x 2!!!

Ambiente de desarrollo en pleno desarrollo
Bueno, otra de las cosas que deseo de mi escritorio es que me sirva como ambiente de desarrollo.
Para eso, necesito tener instalado por lo menos el Netbeans 6.1, y el Glassfish v2.
El Netbeans 6.1 no está en el repositorio, pero por suerte sí el 6.0.1, que dado mi nivel de desarrollo es más que suficiente para lo que necesito hacer.
El tema viene con el Glassfish, que no está disponible desde el momento en el cual se instala el sistema operativo, como pasó con el OpenOffice.org.
Al final, descubrí la trampita. Hay que hacer un "pkg install glassfishv2", lo cual me muestra un par de cuestiones interesantes.
La primera, que es medio complicado tener que hacer una búsqueda por palabras para saber qué paquete instalar, y la segunda (que es peor que la primera) es que no hay un metapaquete que permita, en el futuro, pasar automáticamente de una versión a la siguiente, si uno lo desea.
Atención, que se entienda bien este punto, no me parece mal que haya un paquete específico para el Glassfish V2, ya que si queremos mantener una versión, y probar con la siguiente, podríamos hacer, en el futuro, "pkg install glassfishv3", por ejemplo; el problema está en los que, como yo, quieren tener metapaquetes para este tipo de programas.
[ACTUALIZACIÓN] - Actualicé a la versión snv_101b, y para mi sorpresa, toda la paquetería de Netbeans quedó en versión 6.5, que es la última y flamante. Realmente, un caño. Mis viejos proyectos siguien siendo reconocidos por la nueva IDE, y cuando los ejecuto, aún funcionan. Mis miedos, por ahora, quedan guardados.

Ojo con las actualizaciones
Atención, y mucho cuidado con las actualizaciones, dado que hay ciertas cosas que nos pueden poner los pelos de punta, sobre todo si nuestra máquina no tiene un dual boot (o aún teniéndolo), o si se hizo la instalación por default, como ocurre en el 100% de los casos que conozco (y eso incluye el uso de ZFS como filesystem por default).
El tema viene cuando al ejecutar "pkg refresh", y luego "pkg image-update", y si por algún motivo se genera un error en la actualización del sistema operativo, ya que quedará un ambiente de booteo absolutamente inutilizable, que sólo rebooteará nuestra máquina, sin ningún sistema operativo.
Ante eso, lo primero que nos vendrá a la mente es hacer un "beadm destroy nombre_del_ambiente". Bueno, dado uno de esos bonitos bugs, ocurrirá que el GRUB quedará completamente vacío, motivo por el cual habrá que encontrar formas bastantes extravagantes de recuperar todo nuestro trabajo sobre el entorno OpenSolaris.
Dado lo anterior, el nivel de recuperabilidad del sistema operativo, en caso de problemas (incluso generados por las mismas "características" del mismo), se puede considerar como prácticamente nulo (al menos en la versión que estoy probando).
[ACTUALIZACIÓN] - Luego de algunas actualizaciones, este problema desapareció por completo, y ahora todo me funciona perfectamente en lo que respecta a boot environments. Cool!
Sumado a lo anterior, encontré algunas cosas interesantes respecto de las actualizaciones, como por ejemplo:
- La actualización a snv_94 nunca funcionó. Sencillamente, el sistema operativo rebooteaba sin parar, por lo que tuve que eliminar el boot environment a mano, con el comando beadm destroy.
- La actualización a snv_95 sí funcionó, pero no me dejó arrancar el Sun xVM (VirtualBox) a menos que antes le configure una variable de ambiente (mensaje: Failed to create COM object), específicamente la LD_NODIRECT=1. Esta solución me ha llevado un buen rato para encontrarla. Espero que no se repita la experiencia. De todas formas, intenté instalar un RH4.5, y luego de todo el proceso de instalación, se queda colgado en "booting the kernel". A seguir remando, que hay agua para rato.
- La actualización a snv_101b fue buenísima, no sólo me instaló las últimas versiones de Netbeans, OpenOffice, etc., sino que aparte cambió mucho de lo que antes no me funcionaba. Se puede decir que ahora me anda todo, inclusive la tarjeta WiFi en forma nativa, cosa que verifiqué hoy mismo.

Resumen general, mi general - Just the facts
Como resumen, sólo se puede pensar en que el OpenSolaris es un buen sistema operativo, sus funciones de virtualización están perfectamente armadas, como pasa con el SXDE y SXCE.
Un aspecto interesante es que automáticamente detectó mi tarjeta gráfica, y la puso a trabajar, inclusive activando el entorno Compiz.

Conversión de smbpaswd a tdbsam

2008-03-05T23:41:00.001-02:00

En este artículo veremos la forma de modificar la configuración de un servidor Samba para que las cuentas de los usuarios pasen de almacenarse en el formato smbpasswd (específicamente en el archivo /etc/samba/smbpasswd, por ejemplo), al formato tdbsam.

Esta nota nace como respuesta a algunas necesidades planteadas por usuarios de Samba 3 que, luego de haber estado trabajando un buen tiempo con este producto, descubrieron que un error en la configuración del archivo smb.conf implicó que las cuentas de los usuarios se almacenen en el archivo smbpasswd, en lugar de en la base de datos tdbsam, como es conveniente.

En uno de los casos particulares, se produjo el error de, en lugar de agregar, en el archivo de configuración smb.conf la entrada "passdb backend = tdbsam", se había agregado la entrada "passwd backend = tdbsam", con lo cual, al ejecutar el comando smbstatus, aparecía el mensaje:

Unknown parameter encountered: "passwd backend"
Ignoring unknown parameter "passwd backend"

Como no se había advertido dicho error, se agregaron usuarios, los que fueron depositados en el archivo smbpasswd, en lugar de en la base tdbsam, como se deseaba.

El error lo pude reproducir, y encontré que mi usuario, en la base smbpasswd, aparecía de la siguiente forma:

hecsa:1002:ABBF1A51422B62ABB14FD58A657A9CA6:D4356FE201D376F0FEE4B2A355BA1FB1:[U
]:LCT-47CF4463:

Como dato anecdótico, veamos que el UID que aparece en este archivo es el mismo que aparece en /etc/passwd para este usuario:

hecsa:x:1002:1002::/home/hecsa:/bin/sh

Ahora bien, manos a la obra! Lo que tenemos que hacer es usar el comando pdbedit, con las opciones de exportación e importación de contenidos, de manera que el usuario "hecsa" aparezca en la base de datos tdbsam.

Cambiaremos la entrada en el archivo /etc/samba/smb.conf, pasando de ser "passwd backend = tdbsam" a ser "passdb backend = tdbsam", bajaremos y subiremos el servicio de samba con el comando "/etc/init.d/samba stop; /etc/init.d/samba start".

Entonces ejecutaremos:

servidor:/etc/samba# pdbedit -i smbpasswd -e tdbsam
Importing accout for hecsa...ok

...y listo!

Ya podemos verificar a nuestro usuario, que ahora se encuentra en la base de datos tdbsam.

Segurización de un servidor VHCS2 sobre Ubuntu Server 6.06 - Apache 2 / PHP / Postfix / FTP / iptables

2008-01-27T18:00:00.000-02:00

Segurización de PHP

Una de las primeras cosas que hacemos para segurizar el servidor, es cambiar el php.ini, que en el caso de esta versión de sistema operativo, se encuentra ubicado en /etc/php4/apache2/php.ini.
Se le agregarán las siguientes entradas:

disable_functions = system, exec, shell_exec, passthru, pcntl_exec, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, popen, pclose, ini_alter, virtual, openlog, escapeshellcmd

allow_url_fopen = Off

register_globals = Off

Se debió quitar de la lista una serie de valores que originalmente estaban, como ser:

putenv: Con este valor, no funciona el Squirrelmail.
set_time_limit: Con este valor, no funciona el Webmail OverLook3.

Finalmente, deberemos reiniciar el servidor web para efectivizar los cambios realizados. Eso, como veremos en general en todos los casos, lo hacemos con /etc/init.d/apache2 stop y /etc/init.d/apache2 start.

Segurización de Apache 2

Se cambió el shell por omisión del usuario dueño de la ejecución de apache 2 (en mi caso es el www-data). El shell era /bin/sh, y ahora se configuró el /usr/sbin/nologin.
Al mismo tiempo, se cambió el directorio del usuario del apache, que por mosión era el /home/www-data, por el /dev/null.
Esos dos cambios se realizaron editando directamente el archivo /etc/passwd, localizando la entrada del usuario www-data, y cambiando sus campos para que queden así:

www-data:x:33:33:www-data:/dev/null:/usr/sbin/nologin

Luego se bajó y subió el servidor apache con el comando /etc/init.d/apache2 stop y /etc/init.d/apache2 start.
Se verificó que las páginas existentes funcionen bien, y con eso tenemos el primero de nuestros procesos de segurización de apache 2 finalizado.

Segurización de SSH - Uso de fail2ban

El sistema fail2ban es famoso por reaccionar ante muchos intentos de login fallidos por parte de una direccion IP en particular, impidiendo que se le proporcione el mismísimo promt del ssh.
Este comando reacciona incorporando reglas de iptables en forma automática.
Para implementarlo en Ubuntu 6.06 (viejo al día de la fecha, pero muy buen servidor), se deberá instalar con el típico comando de la suite apt:

# apt-get install fail2ban

Una vez instalado, se podrá recorrer su configuración verificando el archivo /etc/fail2ban.conf, que entre otras cosas, deberá tener:

[DEFAULT] (esta sección tendrá los valores mínimos necesarios para que fail2ban funcione correctamente)
...
logtargets = /var/log/fail2ban.log (archivo donde se logueará el comportamiento de fail2ban)
maxfailures = 5 (cantidad de intentos de login antes de estar baneado)
bantime = 600 (tiempo que el servidor no permitirá conexiones desde esa dirección IP)
...

[MAIL] (esta sección indicará las configuraciones destinadas a enviar un mail cada vez que se banee una dirección IP)
...
enabled = true
host = mail.firulete.com
port = 25
user = webmaster@firulete
password = firulete01
from = fail2ban@firulete.com
to = webmaster@serverremoto.com
...

Luego de estas configuraciones, sólo tendremos que reinicializar el servicio fail2ban con los comandos /etc/init.d/fail2ban stop y /etc/init.d/fail2ban start.
Podremos verificar que el programa está en ejecución mediante un "ps aux | grep fail2ban", que nos entregará algo del estilo "/usr/bin/python /usr/bin/fail2ban".

En breve estaré agregando las secciones correspondientes a la forma de segurizar el servidor de correo, Postfix, el FTP server, y la forma cómo configurar el sistema iptables2 para que tengamos, aparte de todo, un excelente firewall en nuestro servidor VHCS2.

Instalacion de Windows XP, Linux Ubuntu 7.10 y Solaris Express Developer Edition snv_70b en una Dell D630

2008-01-27T14:27:00.000-02:00

Ante todo, como el disco de esta máquina tiene ni más ni menos que 120 GB, lo dividimos en particiones.
Generamos una de 60 GB para Windows, una de 4 GB para el swap de Linux, una de 26 GB para el / de Linux, y una de 30 GB para Solaris Express Developer Edition snv_70b (OpenSolaris, para los amigos).
Para realizar esta instalación, ante todo, implementamos Windows, que es el que mas problemas puede traernos a la hora de pensar en que su boot loader, de instalarse al final, borraría todas las demas opciones de sistemas operativo.

Instalacion de Ubuntu 7.10

Luego, implementamos Ubuntu, y para ello sólo tendremos que utilizar las dos particiones que comenté más arriba.
Por un lado, creamos una partición de swap (en mi caso será la segunda partición del disco) de 4 GB, dado que la Dell D630 tiene 2 GB de RAM; y por el otro, generamos una partición de / de 26 GB.
La instalación luego de estas sencillas consideraciones deberá continuar como es común, dado que el instalador de Ubuntu detectará nuestra tarjeta gráfica, que si bien no está completamente soportada, por lo menos nos permitirá disfrutar de una definición de 1440x900.
No debemos olvidar, dado que luego lo necesitaremos, copiar FUERA DE ESTA MÁQUINA el archivo /boot/grub/menu.lst. Es importantísimo que este copiado, y que sea fuera de esta máquina. Si aún usas papel, es una excelente idea copiarlo a mano, no es tanto!
Dado que SXDE detectará la partición de swap como si fuera una mas de SXDE, deberemos desactivarla, y cambiarle el flag de partición, de linux-swap, a algo del estilo ext2, por ejemplo.
Para hacer eso, hay dos caminos, ambos sencillos.
Uno es utilizar el comando fdisk, con el cual podremos seleccionar la opcion "t", para hacer un toggle del flag de la partición, y otro, que es que yo estuve usando, es la instalación de la utilidad "gparted".
Al abrirlo, podremos ver esa partición, que en mi caso es la segunda del disco, desactivarla, y luego cambiarle su flag por el de ext2. No olvides presionar el botón "Apply" del "gparted" luego de hacer los cambios!
Luego de ejecutar la instalación por omisión, hay ciertas cosas que no quedaron funcionando del todo.
Una de ellas es el sonido. Lo que hice para que funcione fue lo siguiente:

# more /proc/asound/devices
2: : timer
3: : sequencer

Instalé el paquete linux-backports-modules, y agregué las siguientes líneas en el archivo /etc/modprobe.d/alsa-base:

options snd-hda-intel model=dell-m42

Al rebootear, las cosas han cambiado un poco. Al hacer un "more /proc/asound/devices", aparece lo siguiente:

2: : timer
3: : sequencer
4: [ 0- 1]: digital audio playback
5: [ 0- 0]: digital audio playback
6: [ 0- 0]: digital audio capture
7: [ 0- 1]: hardware dependent
8: [ 0- 0]: hardware dependent
9: [ 0] : control

Inmediatamente instalé el paquete alsamixergui, para poder hacer el ajuste fino del volumen. Levanté un poco el volumen, y con el xmms, pude escuchar mis mp3 sin ningún problema.

Otra cosa que no funcionó bien desde el principio fueron los efectos de pantalla. Para ello, lo que hice fue agregar en el archivo /etc/xdg/compiz/compiz-manager la siguiente línea:

SKIP_CHECKS=yes

Nuevamente rebooteé, y probé los efectos. Funcionaron, pero debo cuidarme de no enloquecer con algunos, porque pueden "colgarme" la interface gráfica.

Instalación de SXDE

En la lista de instalaciones, finalmente llegamos al SXDE.
Para instalarlo no hay mucha ciencia, dado que con sólo presionar "F12" en nuestra máquina cuando está arrancando, y luego, en el menú de booteo, seleccionar la entrada de CD/DVD, el SXDE comenzará su proceso de instalación.
La "falta de ciencia" se debe a que, en esta versión de Osol, no podremos especificarle el tamaño de las particiones, por lo que sólo le diremos que utilice el espacio que queda, que será de 30 GB.
Cuando termina de instalarse (aproximadamente una hora, en la Dell D630), rebootearemos el sistema, y veremos con alegría la ventana de login. Pero esto recién empieza!
Tocamos el archivo /boot/grub/menu.lst, para agregarle las entradas de Linux, dado que el boot loader por omisión, ahora, es el implementado por SXDE.
Se le agregan las siguientes entradas:

title Ubuntu 7.12, kernel-2.6.22-14-generic
root (hd0,2)
kernel /boot/vmlinuz-2.6.22-14-generic root=UUID=1ddc3c8e-168b-4f68-ab82-36203ed5dd1b ro quiet splash
initrd /boot/initrd.img-2.6.22-14-generic

Estas entradas, que parecen tan crípticas, son un extracto del /boot/grub/menu.lst de la partición de Linux, que habiamos copiado antes.

Una vez que hayamos salvado esta porción del archivo, y hayamos rebooteado con Linux Ubuntu, no olvidemos volver a configurar el espacio de swap, es decir, dejarlo como estaba antes. Para eso, volvemos a ejecutar el "gparted", tal como lo hicimos en la sección anterior.

Luego de rebootear para ver que todo funciona bien, tendremos un gran problema, y es ver que nuestra tarjeta de red, una Broadcom NetXtreme, basada en el chipset 5755M, no levanta para nada.
Luchando contra el hardware, encontre un link que apuntaba a poder bajar un driver del sitio "opendrivers".
Luego de bajarlo, lo instale con:

# pkgadd -d ./BRCMbcme.pkg

...y la tarjeta de red, luego de un

# ifconfig bcme0 plumb
# ifconfig bcme0 192.9.200.3 netmask 255.255.255.0 up

...quedó funcionando.

Virtualización de linux 2.4 y 2.6 con Brandz en OpenSolaris

2008-01-20T15:41:00.011-02:00

Procedimiento rápido para la generación de una Brand Linux 2.4 y 2.6 con OpenSolaris (SXDE, SXCE y OpenSolaris)

Éste es un procedimiento para generar una zona de linux 2.4 ó 2.6, usando el esquema de virtualización BrandZ de OpenSolaris.
Como habrán podido notar, no se soporta aún la implementación de una Brand desde el CD de instalación de la misma distro de GNU/Linux, por lo que se deberá generar, previamente, usando un sistema operativo ya instalado, mediante los comandos:
# cd /
# tar jcf distro24.tar.bz --exclude distro24.tar.bz --exclude dev --exclude proc --exclude sys --exclude boot *
Sencillamente, para generar una brand de linux 2.4, que por omisión posee sus archivos xml de configuración en el sistema operativo inmediatamente después de haber sido implementado, se deberán seguir estos pasos:

# mkdir /zones (éste será el directorio donde se depositarán los archivos correspondientes a la zona que vamos a crear)
# zonecfg -z linux24 (éste será el nombre que le daremos a esta zona)
linux24: No such zone configured (lógicamente, como aún no existe, aparecerá este mensaje)
Use 'create' to begin configuring a new zone.
zonecfg:linux24> create -t SUNWlx (aquí creamos la nueva zona, basándonos en el template SUNWlx)

Si el brand a generar fuera del tipo de kernel 2.6, habría que ejecutar, en lugar del anterior, el siguiente comando:
zonecfg:linux24> create -t SUNWlx26 (aquí creamos la nueva zona, basándonos en el template SUNWlx26, similar al anterior)

zonecfg:linux24> set zonepath=/zones/linux24 (aquí anunciamos cuál será el path donde se ubicarán los archivos de esta zona)
zonecfg:linux24> set autoboot=true (esto sólo lo agregamos si queremos que cuando bootee el equipo, es decir, la zona global, también bootee la zona linux24)
zonecfg:linux24> add capped-memory (al principio no hacía esto, pero luego de ver cómo una zona podía comerse toda mi RAM, lo tomé como buena práctica)
zonecfg:linux24:capped-memory> set physical=128m (sólo le doy 128 Mbytes. Soy tacaño)
zonecfg:linux24:capped-memory> set swap=256m (el doble de RAM para el swap, también limitado, y también una buena práctica para evitar que los recursos sean comidos por esta zona)
zonecfg:linux24:capped-memory> end (finalización de la configuración de la memoria limitada)
zonecfg:linux24> add net (aquí agregamos una interface de red a la zona)
zonecfg:linux24:net> set address=192.9.200.105/24 (aquí configuramos la dirección de red de esta interface de red, nótese cómo el prompt cambió, y ahora tiene como último elemento la palabra "net")
zonecfg:linux24:net> set physical=bge0 (le decimos que la tarjeta de red por la cual se deberá salir es la bge0)
zonecfg:linux24:net> end (finalizamos la configuración de la tarjeta de red)
zonecfg:linux24> add attr
zonecfg:linux24:attr> set name="audio" (agregamos un atributo, que será la utilización de una interface de audio)
zonecfg:linux24:attr> set type=boolean
zonecfg:linux24:attr> set value=true
zonecfg:linux24:attr> end
zonecfg:linux24> commit (hacemos efectivos los cambios)
zonecfg:linux24> exit (salimos de la configuración de la zona linux24)
# zoneadm -z linux24 install -d /Documents/distro24.tar.bz2 (atención, antes de poder instalar la zona, debemos poseer un archivo con el árbol de archivos de una distro basada en el kernel 2.4, tareada y bzipeada)

- Aquí veremos aparecer mensajes como éstos:
Installing zone 'linux24' at root directory '/zones/linux24'
from archive '/Documents/centos_fs_image.tar.bz2'
This process may take several minutes.
Setting up the initial lx brand environment.
System configuration modifications complete.
Setting up the initial lx brand environment.
System configuration modifications complete.
Installation of zone 'linux24' completed successfully.
Details saved to log file:
"/zones/linux24/root/var/log/linux24.install.2453.log"

# zoneadm -z linux24 boot (booteamos la zona linux24)
# zlogin -C linux24 (le decimos -C para que arranque la consola, y podamos ejecutar los pasos de configuración que faltan)

- Aquí finalizará la instalación de la zona linux. Salir de la
consola con ~.

# zlogin linux24 (ahora sí, con el sentimiento del deber cumplido, nos logueamos a esta zona)

Luego, algo importante a realizar, si es que vas a realizar instalaciones de productos que tienen grandes dependencias con los nombres de los servidores, es cambiar el archivo /etc/hosts de forma tal que contenga entradas como las siguientes:

127.0.0.1 localhost.localdomain localhost
192.9.200.105 linux24.hecsa.com.ar linux24

Ahora bien, para bajar esta zona linux 2.4, sólo tendremos que ejecutar:

# zoneadm -z linux24 halt

Nada más para una zona linux con kernel 2.4 (medio viejo al día de la fecha, pero sirve para unas cuantas cosas, como en mi caso, que pruebo si me funcionan viejos programas).

Esto que has visto en las notas de más arriba, lo reproduje bajándome el archivo SUNWlx26.xml, e instalando un CentOS 4 update 5, es decir, una distro basada en RPM's, y con kernel 2.6.x, y me anduvo perfectamente.

UN DETALLE INTERESANTE es que hay diferencias notables de espacio cuando la máquina virtualizada está en funcionamiento, y cuando se baja:

a) Funcionando:

-bash-3.2# du -ks ./*
5817 ./bin
1 ./boot
3 ./dev
42021 ./etc
12 ./home
1 ./initrd
86294 ./lib
1 ./lost+found
4 ./media
1 ./misc
1 ./mnt
3128241 ./native
1 ./opt
21 ./proc
289 ./root
17527 ./sbin
1 ./selinux
1 ./srv
28 ./tftpboot
44 ./tmp
1759444 ./usr
47876 ./var

b) Sin funcionar:

-bash-3.2# du -ks ./*
5817 ./bin
1 ./boot
1 ./dev
42021 ./etc
12 ./home
1 ./initrd
86294 ./lib
1 ./lost+found
4 ./media
1 ./misc
1 ./mnt
21 ./native
1 ./opt
1 ./proc
290 ./root
17527 ./sbin
1 ./selinux
1 ./srv
28 ./tftpboot
43 ./tmp
1759444 ./usr
47876 ./var

Dónde es que está la diferencia? Fíjense en el directorio /native. Ahí tienen unos 3 GB.
Eso se debe a que cuando no está funcionando todos sus directorios, que son dev, etc, lib, proc, tmp, usr y var, están vacíos, pero cuando arranca la máquina virtualizada, se llena con contenidos típicos del GNU/Linux que está en ejecución.

Ahora bien, si la prueba salió bien, y queremos eliminar esa zona, qué comandos utilizaríamos? Eso es bien sencillo, sólo hay que ejecutar dos comandos (atención, no hay undo de estos comandos, así que a ejecutarlos con bastante cuidado!):

# zoneadm -z linux24 uninstall
# zonecfg -z linux24 delete

Así de sencillo!

Apéndice: Diferencias entre el archivo SUNWlx.xml y el SUNWlx26.xml

A simple vista (con perdón de la palabra), las diferencias que existen entre el archivo SUNWlx.xml y el SUNWlx26.xml es sólo la línea, por lo que la sección que la contiene quedaría:

Eso es todo, y con esta línea extra se podrá generar el archivo en cuestión.

Suerte con las pruebas!!!

HeCSa.