martes, 27 de julio de 2010

DRAFT – Compilación de actualizaciones

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".

domingo, 20 de junio de 2010

Sobre Cyborgs y demás yerbas

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.

viernes, 14 de mayo de 2010

OpenSolaris y sus servicios



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.

image
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.

image
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:

image
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.

jueves, 13 de mayo de 2010

Software e ideología

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.

lunes, 8 de marzo de 2010

Bio (for OGB elections)

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

domingo, 7 de marzo de 2010

Configuración de IP estática con NWAM

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!