Título Dilbert.

Texto El humor es uno de los ingredientes que nos hacen la vida más agradable. Dentro de él, el humor gráfico tiene muchas vertientes: desde aquéllos que apenas necesitan acompañar las imágenes con

palabras para hacernos esbozar una sonrisa, como Sempé1,o uno de sus más aventajados seguidores, Quino2. Éste último es sobre todo conocido por su tira cómica del

personaje Mafalda3.

La tira TIC por excelencia es Dilbert, creada por Scott Adams.

Su éxito es tal que incluso ha inspirado el llamado Principio de Dilbert, que es una variación del de Peter.

En la misma aparecen una serie de personajes alrededor del

mundo del trabajo en una compañía dedicada a producir productos tecnológicos (no podemos concretar más puesto

que una de las características es el caos que acompaña a dicha empresa). Así, aparte del propio Dilbert, un ingeniero, están su colega

Wally, el Jefe, Dogbert, la mascota de Dilbert y que actúa como consultor (!), etc.

Las situaciones reflejadas en Dilbert son las cotidianas en una empresa, sazonadas con un tono mordaz y absurdo pero, a la

vez, fiel reflejo de la realidad.

Adams no deja títere con cabeza y abarca todos los conceptos

que rigen la actividad de una empresa, empezando por la

orientación al cliente: - (Jefe): Nos tenemos que preguntar constantemente lo

qué podemos hacer para tener contentos a nuestros clientes.

- (Alice): Podríamos dejar de hacer estas reuniones,

echar a todos los presentes y reducir los precios de nuestros productos.

- (Jefe): Estaba pensando más bien en un eslogan... - (Wally): ¿Qué tal: 'Despilfarramos su dinero'?

Siguiendo por la, a veces, difícil relación entre los

departamentos comerciales y técnicos: - (Dilbert): Stan, le prometiste cosas al cliente que el

departamento de ingeniería no puede realizar. ¿Sabes lo que eso significa?

- (Stan): Significa que soy un gran vendedor y tú eres

un mal ingeniero. Tal vez te convendría tomar clases nocturnas.

- (Dilbert, pensando): Sí, de karate.

Por supuesto las relaciones entre jefe y empleado son objeto de numerosas tiras:

- (Jefe): Alice, me cuentan que pasas tiempo con tu familia por la noche. Este tiempo lo podrías aprovechar

para trabajar sin cobrar extra. - (Alice): ¿Tiene usted familia? - (Jefe, pensando): Hmmm... Eso explicaría la gente que

hay en mi casa... ● ● ●

- (Jefe): Hemos rediseñado el organigrama para mostrar la Dirección en el rango más bajo. Como símbolo de cómo apoyan a nuestros empleados más importantes.

- (Dilbert): Pregunta: ¿por qué los empleados más importantes son los que menos cobran?

- (Jefe): Porque a ellos nunca se les ocurrirían ideas como este concepto de organigrama invertido.

● ● ● - (Dilbert): Aquí tiene mi hoja de horas trabajadas,

rellenada en incrementos de quince minutos. Y aquí

tiene mi informe de estado mensual, mi previsión de gastos, mis trabajos cumplidos, mi lista de peligros...

- (Jefe, pensando): Nunca tan poco se ha medido tanto. ● ● ●

- (Jefe): Aunque técnicamente soy 'El Jefe', creo que es

mi trabajo proporcionarles los recursos necesarios a ustedes, los empleados.

- (Dilbert): Necesito más dinero para mi proyecto. - (Jefe): Lo siento. Ya no queda nada. - (Dilbert): Tal vez le pida una cita para poder hablar del

tema.

- (Jefe): Tengo veinte minutos en mi agenda, pero

habrá que esperar hasta el verano que viene.

Las reuniones, cómo no, dan también mucho argumento: - (Wally, a Dilbert): Aquí tienes la tarjeta de bingo para

la reunión. Si el jefe utiliza una palabra clave que aparece en tu tarjeta, la tachas. El objetivo es tachar

una línea. - (Jefe): Hoy están todos muy atentos. Veo que mi

liderazgo proactivo está surtiendo efecto. - (Wally): Bingo, señor.

Y también las certificaciones: - (Jefe): Te nombro responsable de nuestro proyecto

para conseguir la certificación 'ISO 9000'. No sabemos

de qué se trata, pero queda muy bonito en los folletos de empresa.

- (Dilbert): Creo que certifica que seguimos procesos

consistentes. - (Jefe): Sí... Siempre mentimos en nuestros folletos.

También hay nuevas incorporaciones a las que cuidar: - (Jefe): Matt acaba de salir de la escuela de ingenieros.

Tú vas a ser su mentor. Hagas lo que hagas no le

aplastes el espíritu antes del miércoles. - (Dilbert): ¿Por qué aplazarlo tanto? - (Jefe): Porque aposté 10 pavos a que podríamos hacer

que aguante hasta el jueves.

Así como funciones que clarificar: - (Dilbert): Como todos saben, me han nombrado líder

del equipo. - (Alice): ¿Decides los aumentos de sueldo? - (Dilbert): No. - (Alice): ¿Apruebas los gastos? - (Dilbert): No. - (Alice): ¿Puedes despedir a la gente? - (Dilbert): No. Soy un líder, no un jefe. - (Alice): Bien, vete y nosotros te seguiremos.

Finalmente, se satiriza lo absurdo que, a veces, es la

tecnología: - (Ordenador): Para configurar la aplicación, introduzca

el nombre del ganador del año que viene del Oscar al mejor actor.

- (Dilbert teclea algo) - (Ordenador): Por favor, espera.

Algunos de los dogmas de Dogbert: Todos los trabajos son asignados a la persona que

menos los entiende.

Todas las empresas necesitan una estrategia para que

los empleados sepan cuál no es su trabajo. Un optimista no es más que un pesimista sin

experiencia laboral. Todos los rumores son auténticos... sobre todo si tu

jefe los desmiente. Cualquier estrategia acertada parecerá ridícula cuando

se lleve a cabo. Lo que haces es mucho menos impresionante de lo

que implica tu cargo. Un experto es una persona que ha sido asignado a un

trabajo para expertos. No se necesitan más

cualificaciones.

Se atribuye a Guy Kawasaki la siguiente frase: 'Hay dos tipos de compañías, las que reconocen que son exactamente como

la de Dilbert y las que también lo son pero aún no lo saben.'

Puede parecer que lo aquí expresado sólo serviría como

desahogo para personas quemadas. Pero si bien esto es cierto, quedarse en este estadio sería simplificar las cosas. En mi opinión las tiras de Dilbert, y otros libros de Scott

Adams, sirven como diagnóstico y reflejo de una realidad que sirven para desdramatizar situaciones pero no para olvidarlas,

sino corregirlas. Además cuando uno ve que en todos los sitios cuecen habas, empieza a relajarse y a reírse de sí mismo, lo cual suele ser

un signo de inteligencia.

¿Una última perla? ¡Venga! - (Ejecutivo): Yo pronostico que no venderemos nada

durante los dos primeros años, y que después despegarán repentinamente.

- (Dilbert): ¿Por qué? - (Ejecutivo): El aumento lo añadí para que me

aprobaran el proyecto. El plazo de dos años me da tiempo para que me asciendan.

- (Dilbert): ¿Y qué hay de las responsabilidades? - (Ejecutivo): Aquí es donde entras tú en juego.

Quien piense que este es un artículo frívolo, puede leer el

último libro de Tom DeMarco y compañeros, que también trata todos estos temas.

Referencias: La tira diaria. Libros en español. Adrenaline Junkies and Template Zombies:

Understanding Patterns of Project Behavior. Si quieres enviar algún comentario o sugerir temas a tratar en otros artículos, escribe a: curtasun[simboloArroba]cein.es

Categorías General

Tema Desarrollo

Autor Carlos Urtasun

Mes Septiembre

Año 2008

Boletín 09

Títul

o XSL-FO (Parte 3): objetos.

Texto

Ahora que ya hemos dado el formato al documento, vamos a ver los tipos de objetos que pueden aparecer en el mismo. Imágenes Este elemento, por sí mismo se considera un objeto inline: sin embargo, se puede convertir en otro de nivel de bloque incluyéndolo

en un objeto como fo:block. <fo:block text-align="center"> <fo:external-graphic width="8mm" height="15mm" src=” file:../graphics/image.gif” /> </fo:block>

Líneas guía

El elemento que crea una línea guía es fo:leader. Debe ir dentro de un elemento block. Contiene el atributo leader-pattern con los posibles valores space, rule, dots, use-content e inherit. Su estilo viene definido por rule-

style, y su longitud por leader-length. Su grosor lo define rule-thickness.

En el ejemplo, se crea lo que suele ser un formato de fecha: Fecha:_______ de_________ de______

<fo:block text-align="center"> Fecha: <fo:leader leader-pattern="rule" leader-length="8mm" rule-thickness="0.3mm"/> de <fo:leader leader-pattern="rule" leader-length="30mm" rule-thickness="0.3mm"/> de <fo:leader leader-pattern="rule" leader-length="10mm" rule-thickness="0.3mm"/> </fo:block>

Tablas Son objetos de formato de nivel de bloque. El elemento es fo:table. Se debe definir el número de columnas que

tiene la tabla en fo:table-column con el ancho de cada una de ellas, en su atributo column-width. Lo siguiente es crear el cuerpo de la tabla con sus filas y sus celdas, donde se pintan los datos. Las tablas también pueden tener cabecera (table-header) y pie (table-footer). Esto se ve claramente en un ejemplo: <fo:block space-before="3mm"> <fo:table table-layout="fixed"> <fo:table-column column-width="15mm" /> <fo:table-column column-width="20mm" number-columns-repeated=”2”/> <fo:table-footer> <fo:table-row> <fo:table-cell number-columns-spanned="3"> <fo:block text-

align="end" font-size="7pt"> Este es el pie de la tabla </fo:block> </fo:table-cell> </fo:table-row> </fo:table-footer> <fo:table-header> <fo:table-row keep-with-next="always"> <fo:table-cell> <fo:block>

<xsl:text>&#160;</xsl:text> </fo:block> </fo:table-cell> <fo:table-cell display-align="center" border-bottom-

width="1pt" border-bottom-color="black" border-bottom-style="solid" padding-after="1mm" padding-before="1mm"> <fo:block text-align="start" font-size="8pt"> <xsl:text> cabecera columna 2 </xsl:text>

</fo:block> </fo:table-cell> <fo:table-cell display-align="center" border-bottom-width="1pt" border-bottom-color="black" border-bottom-

style="solid" padding-after="1mm" padding-before="1mm"> <fo:block text-align="start" font-size="8pt"> <xsl:text> cabecera columna 3 </xsl:text> </fo:block> </fo:table-cell> </fo:table-row>

</fo:table-header> <fo:table-body> <fo:table-row keep-with-next="always"> <fo:table-cell> <fo:block> <xsl:value-

of select="@dato1"/> </fo:block> </fo:table-cell> <fo:table-cell> <fo:block> <xsl:value-of select="@dato2"/> </fo:block> </fo:table-cell> <fo:table-cell> <fo:block> <xsl:value-of select="@dato3"/> </fo:block> </fo:table-cell> </fo:table-row> </fo:table-body> </fo:table> <fo:block>

A destacar el atributo number-columns-repeated en fo:table-column, que nos dice el número de columnas de ese mismo tamaño a crear. A todas las celdas se les puede pintar borde superior, inferior, derecho o izquierdo, de diferente grosor, color y tipo. Además, con

el atributo display-align, le decimos en qué lugar en vertical de la celda, mostrar el contenido. Para que no se produzca un salto de página entre filas, se usa el atributo keep-with-next, o keep-with-

previous.

Listas Para formar una lista se utiliza el elemento fo:list-block. Es un contenedor de ítems que se muestran en forma de lista. Cada uno

de estos elementos, contiene un fo:list-item que es cada ítem de la lista, el cual contiene una etiqueta (fo:list-item-label) y su contenido (fo:list-item-body).

Hay varios atributos importantes para crear una lista, a saber: provisional-distance-between-starts: es un atributo de list-block. Nos

dice la distancia que hay entre el comienzo del área de la etiqueta y el comienzo del área del contenido del ítem. Este valor no se usa directamente, sino que vale para calcular la función body-start(). provisional-label-separation: es un atributo de list-block. Nos marca la distancia que hay entre el final de la etiquta y el principio del

contenido del ítem. Este valor no se usa directamente, sino que vale para calcular la función label-end(). La función body-start() se usa como valor del atributo start-indent

del elemento fo:list-item-body, y la función label-end() se usa como

valor del atributo end-indent del elemento fo:list-item-label.

Ejemplo: <fo:list-block provisional-distance-between-starts="20mm" provisional-label-separation="10mm"> <fo:list-item> <fo:list-item-label end-indent="label-end()" start-

indent="6mm"> <fo:block>&#x2022;</fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()" end-indent="90mm"> <fo:block>contenido1</fo:block> </fo:list-item-body> </fo:list-item> <fo:list-item> <fo:list-item-label end-indent="label-end()" start-

indent="6mm"> <fo:block>&#x2022;</fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()" end-

indent="90mm"> <fo:block>contenido2</fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block>

Notas a pie de página El objeto fo:footnote define una nota a pie de página dentro de region-body de una página. Tiene dos hijos: fo:inline (referencia de

la nota) y fo:footnote-body (contenido de la nota). Ejemplo: <fo:block font-size="10pt">Este es el texto en el que voy a insertar una <fo:footnote> <fo:inline>nota</fo:inline>

<fo:inline vertical-align="super">1</fo:inline> <fo:footnote-body> <fo:block>1. Este es el contenido de la

nota</fo:block> </fo:footnote-body> </fo:footnote> aquí sigo con el texto </fo:block>

Si a este ejemplo le añadimos leader y list, quedaría así:

<fo:block font-size="10pt">Este es el texto en el que voy a insertar una <fo:footnote> <fo:inline> nota</fo:inline> <fo:inline vertical-align="super">1</fo:inline> <fo:footnote-body> <fo:block text-align-last="justify"> <fo:leader leader-pattern="rule"/> </fo:block> <fo:list-block> <fo:list-item> <fo:list-item-label end-

indent="label-end()">

<fo:block>1</fo:block> </fo:list-item-label> <fo:list-item-body start-indent="body-start()"> <fo:block> Este es el contenido de la nota </fo:block> </fo:list-item-body> </fo:list-item> </fo:list-block> </fo:footnote-body> </fo:footnote> aquí sigo con el texto </fo:block>

Marcadores (Runnig headers) Se suele utilizar en cabecera o pie de página para mostrar algún

texto, como por ejemplo, en los diccionarios en los que en la cabecera se muestra la primera palabra por la que empieza esa página y la última en la que acaba. Su contenido cambia en función

del flujo. Consta de dos elementos necesarios: fo:marker y fo:retrieve-

marker. El elemento fo:marker nos dice qué texto queremos que se pinte. Se suele colocar dentro de un block. Tiene un atributo marker-class-

name que contiene el nombre del marcador. El elemento fo:retrieve-marker se suele colocar en la cabecera o el pie (siempre en un fo:static-content), lugar donde se pintará. Tiene

el atributo retrieve-class-name con el nombre del marker que queremos mostrar, es decir, el valor de marker-class-name deberá coincidir con el valor de retrieve-class-name. Este elemento tiene

además otro atributo interesante, retrieve-position que nos indica la posición del texto a mostrar, es decir, si mostrará la primera o la

última Ejemplo: En el flow: (Es como si dijéramos: utilice este contenido cuando

quiera el contenido del marker llamado título)

<fo:block> <fo:marker marker-class-name="titulo"> <fo:block> <xsl:value-of select="."/> </fo:block> </fo:marker> </fo:block>

En el static-content:

<fo:block> <fo:retrieve-marker retrieve-class-name="titulo" retrieve-position="first-starting-within-page" retrieve-boundary="page"/> </fo:block>

Enlaces El elemento que introduce los enlaces es el fo:basic-link. El enlace a un documento remoto, lleva su URI en el atributo external-

destination. Si el enlace te lleva al mismo documento, la URI va en el atributo internal-destination. Así, un basic-link solo tendrá uno de estos dos atributos. El documento destino se puede elegir dónde

abrirlo gracias a otro atributo: show-destination. Si su valor es new, se abre en una nueva ventana, y si es replace, se cargará en la

misma ventana. Esta última opción es la que viene por defecto. <fo:block> <fo:basic-link external-destination="http://www.google.es"> Enlace </fo:basic-link> </fo:block>

En el siguiente ejemplo, vamos a ver cómo se haría un índice con enlaces a las propias páginas del documento:

<fo:block font-size="18pt" font-weight="bold" text-align="center"> Índice

</fo:block> <fo:block text-align-last="justify"> <fo:basic-link color="blue" internal-destination="capitulo1"> Título 1 </fo:basic-link> <fo:inline keep-together.within-line="always"> <fo:leader leader-pattern="dots"/> <fo:page-number-citation ref-id="capitulo1" /> </fo:inline> </fo:block> <fo:block id="capitulo1" break-before="page" font-size="18pt"> Título 1 </fo:block>

Referencias: http://zvon.org/xxl/xslfoReference/Output/index.html

Categorí

as

CES OpenSouce/Java

Tem

a

Varios

Autor

Raquel Urdangarin

Mes Septiembre

Año 2008

Boletín

09

Título Implantación de Nagios (Parte 2).

Texto TOPOLOGIA E INTERPRETACIÓN DE RESULTADOS

En el anterior artículo descubrimos Nagios y analizamos la forma

de instalarlo en nuestra red. Esta parte pretende ajustar la configuración de los recursos que monitorizar a nuestras

necesidades.

1 Configuración de los parámetros de funcionamiento:

La forma de configurar nagios para adaptarlo a nuestros

requerimientos es editar varios ficheros de configuración.

Definición de máquinas a monitorizar: tendremos que añadir a

/etc/nagios/hosts.cfg una nueva entrada por cada host, respetando

una "plantilla":

define host{

use generis-host ; Nombre de la plantilla a utilizar

host_name irati ; Nombre de la máquina

alias Javacenter Server 1 ; Alias

address 192.168.14.145 ; IP

check_command check-host-alive ; Comando que utilizamos para comprobar la disponibilidad de la maquina

max_check_attempts 10 ; Opciones de chequeo y notificación...

notification_interval 120 ;

notification_period 24x7 ;

notification_options d,u,r ;

}

En esta plantilla vemos los parámetros que definirán el host, como

nombre y alias, la dirección de red. Además de estos podemos definir como se va a comprobar la disponibilidad de la máquina

(check_command) y parámetros de intentos de comprobación y notificación de alertas.

Definición de grupos de máquinas: es útil para separar redes o

diferenciar tipos de máquinas. Tenemos que editar otro fichero (hostgroups.cfg). La dinámica es similar a la de hosts.cfg (y a la de

todos los ficheros de configuración)

define hostgroup{

hostgroup_name printers

alias Javacenter Printers

contact_groups admins

members printer1,printer2

}

El grupo tiene un nombre, un alias, un grupo de contacto y los

miembros. En este caso mostramos el grupo de las impresoras.

Definición de monitoreo de servicios, este es uno de los

ficheros trascendentales para el perfilar el monitoreo, en el fichero services.cfg se definen todos los servicios que se van a checkear

en cada hot.

define service{

use generic-service ; Nombre del “servicio plantilla” a usar

host_name gw,kirnis,isis,mider,rea,isthar

service_description PING

is_volatile 0

check_period 24x7

max_check_attempts 3

normal_check_interval 5

retry_check_interval 1

contact_groups admins

notification_interval 240

notification_period 24x7

notification_options c,r

check_command check_ping!100.0,20%!500.0,60%

}

Al definir el servicio incluiremos el host o hosts a los que se les va aplicar, una descripción, parámetros de checkeo, reintentos y

notificaciones, y además el comando que vamos a usar en el servicio. Como se ve en el ejemplo, el comando es check_ping!100.0,20%!500.0,60%

Realmente el comando llama a un plugin (que previamente ha sido instalado) y le pasa los parámetros adecuados en cada caso,

porque dependiendo del plugin necesitara unos u otros. Aunque seguramente siempre estén los umbrales que definen en qué

situación está el servicio que queremos monitorizar.

El modo de funcionamiento de nagios es comprobar en qué estado

se encuentra el recurso observado. Estos estados se establecen en la definición del servicio y suelen ser ESTADO NORMAL, ALERTA y CRITICO aunque dependerá del plugin en cada

caso.

Si por ejemplo queremos monitorizar el estado en el que se

encuentra el disco duro de una máquina, establecemos que un uso menor de 60% es el estado NORMAL, entre 60% y 90% ALERTA y

más de 90% CRITICO. Una vez definido el servicio, el demonio de nagios consultará el plugin correspondiente y mostrará el resultado obtenido en la interfaz web. La sintaxis seria la siguiente:

check_disk!40%!10%!/dev/sda1 ( los umbrales y el dispositivo a monitorizar )

Los plugins en este caso están instalados

en /usr/lib64/nagios/plugins/ y podemos ver desde monitores

de la carga del procesador, el estado de la RAM o de servicios http como servidores ftp o web. Además de los proporcionados por

nagios existen numerosos creados por la comunidad.

Hay que tener en cuenta que estos plugins sólo son capaces

de trabajar en modo local, es decir, sólo pueden trabajar con datos de la máquina en la que se ejecutan. Para poder monitorizar datos remotos necesitamos la ayuda de otro

plugin (check_nrpe) que hace de proxy entre el demonio de nagios y los plugins que se encuentran en la máquina remota.

Lógicamente en la máquina remota también estará ejecutándose otro demonio o servicio que se encargará de recoger la petición del plugin desde el servidor, llamare al plugin correspondiente y

devolver el resultado al servidor, como hemos comentado antes.

Entonces para definir un servicio remoto debemos utilizar siempre

el plugin check_nrpe, con lo que la sintaxis quedaría de la siguiente forma:

check_nrpe!check_disk!c:!150!200

Se le llama al nrpe y como argumentos se le pasa el plugin a

ejecutar con sus respectivos umbrales. Hay que tener en cuenta que la definición del comando puede ser sensible al sistema

operativo de la máquina.

Comentar que también en cada máquina remota a monitorizar hay que configurar el demonio que atienda las peticiones del plugin

check_nrpe y copiar los plugins que vayamos a necesitar. Habrá que adecuar a nuestra configuración un fichero de configuración

(nrpe.cfg) en el que se definen el puerto, los clientes aceptados, si se utiliza ssl, y demás parámetros de funcionamiento, así como los

plugins ofertados. Por ejemplo si queremos que se pueda acceder al plugin de comprobación de uso de disco, tenemos que definirlo, indicar la ruta al ejecutable y establecer la forma en la que se le

pasarán los argumentos

command[check_disk]=C:\nrpe_nt\plugins\diskspace_nrpe_nt.exe $ARG1$ $ARG2$ $ARG3$

De esta forma iremos definiendo los servicios que nos interesen y

podremos empezar a recoger los datos devueltos. Además se pueden definir grupos de contacto, formas de notificación y

estructuras que nos faciliten el tratamiento de esa información.

2 Visualización de los datos recogidos por Nagios:

Parte de los requerimientos de la instalación de Nagios eran

disponer de servidor Apache2 y de un sistema de archivado de los

datos recogidos que varía entre un sistema basado en ficheros de

texto o basados en bases de datos relacionales. En este ultimo caso podíamos optar entre un motor de base de datos MySQL o

PostGresSQL: nosotros hemos optado por MySQL.

La visualización y cierto grado de gestión de Nagios se hacen a

través de un interfaz web que se integra en Apache2 durante el proceso de instalación.

Existen otros de interfaces gráficos desarrollados por terceros más

ricos y amigables. Sin embargo hemos probado el que ya viene montado en la distribución de Nagios. La elección de otros tipos de

herramientas de para interactuar con Nagios queda para otro momento.

Repasar todas las opciones del interfaz gráfico llevaría mucho

tiempo, así que hemos seleccionado 4 muestras. Aunque hay

muchas más hemos seleccionado éstas porque representan el estatus de los servicios que monitorizamos, reflejan el almacenamiento y registro de los datos recogidos y la

configuración de servicio.

Service Detail: esta captura representa la opción service detail.

Esta opción está localizada en la zona “Monitoring” y muestra el estado de todos los servicios definidos para ser monitorizados.

Alert History, localizado en la zona “Reporting”, nos muestra un

histórico de las alertas producidas.

Notifications, también en la zona Reporting, muestra las

notificaciones realizadas (esto todavía esta en fase de implementación)

host: esta opción está localizada en la zona configuration.

Deberemos seleccionar qué aspecto de la configuración de nagios queremos observar, ya sean los servicios, los host, plugins etc. En este caso hemos seleccionado “host”, que representa las

estaciones de trabajo, servidores e impresoras.

Categ

orías

CES OpenSouce/Java

Tema Arquitectura

Autor Igor Unanua

Mes Septiembre

Año 2008

Boletín

09

Títu

lo Proyecto piloto TDT: parte 1: definición

Texto

15 de Octubre del 2006: “Has sido seleccionado para Responsable del Centro Java y Open Source”, no cabía en mi de

gozo...eso ayudaría a afrontar lo que se avecinaba, “el 23 de Noviembre hay una reunión en NGA para conocer la

encomienda del proyecto que nos han encargado y para

presentarte como responsable, hazlo bien, mucho depende de este proyecto”.

Esta frase marcaría mi periplo durante el 2007, cuya experiencia trataré de transmitir a lo largo de este y los

próximos artículos.

Así pues, allí me encontraba, el 23 de noviembre, esperando mi bautismo como “responsable” ante NGA y Gobierno, frente a un

conjunto de personas que posteriormente se perfilarían como el comité de seguimiento y la dirección del proyecto, es decir, las

personas con las que tenía que trabajar y aquellas a las que debía informar.

En esa dirección estábamos yo, como responsable, una persona de NGA y otra de la DGpSI. Nuestras funciones consistían en

dirigir el avance del proyecto llevándolo a buen puerto, cumpliendo los objetivos marcados, tomando las decisiones

pertinentes y llevando a cabo las acciones necesarias, todo de forma consensuada. Así mismo, este equipo debía rendir

cuentas ante el comité sobre el avance y acciones. Este comité lo formaban representantes de CEIN, NGA y DGpSI.

Esa reunión nos puso caras a todos y nos fue entregada oficialmente la encomienda del proyecto que llevaba por título:

PLIEGO DE PRESCRIPCIONES TÉCNICAS DE LA ENCOMIENDA A

NGA PARA EL DESARROLLO EN LOS CENTROS DE EXCELENCIA DE UN PROYECTO PILOTO PARA EL DISEÑO E IMPLANTACIÓN

DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y MANTENER SERVICIOS INTERACTIVOS A TRAVES DE LA

TELEVISIÓN DIGITAL TERRESTRE (TDT)

A continuación resumo los puntos más importantes:

¿Porque la TDT y su papel para la administración?

La tendencia actual es que la información sea accesible

desde cualquier parte y con cualquier terminal. La familiaridad, comodidad, penetración y alcance de la TV

la convierten en un dispositivo preferente para extender la Sociedad de la Información, para favorecer

participación del tele-espectador (interactividad) y reducir la “brecha digital”: aquella población sin posibilidades de

acceder a Internet por edad, reticencia, disposición,

educación o poder adquisitivo.

Por tanto, la TDT permite acercar la administración

electrónica a aquellos ciudadanos a los que resulta difícil

llegar a través de Internet: ancianos, niños, discapacitados, desempleados, ciudadanos con retas más,

menor formación, etc, proporcionando a la ciudadanía un nuevo canal de Servicios Administrativos de interés

público y la posibilidad de participar = una sociedad de la

información amplia, participativa y democrática.

Objetivos

Creación de aplicaciones sobre el estándar MHP (Multimedia Home Platform) que permitan la integración

de contenidos interactivos en la TDT (Televisión Digital Terrestre), y establecer un nuevo canal entre la

Administración y los ciudadanos potenciando el desarrollo de la e-Administración.

Aprendizaje y transferencia de conocimiento a las empresas del sector TIC de Navarra mediante el

desarrollo del proyecto en los Centros de Excelencia. Había una serie de objetivos añadidos entres lo que cabe

destacarse: potenciar la TDT y modernizar la administración.

Alcance del proyecto

Definición de especificaciones y puesta en marcha de la plataforma tecnológica necesaria para la generación y

mantenimiento de aplicaciones interactivas en TDT sobre el estándar MHP.

Desarrollo de un conjunto de servicios hacia el ciudadano (priorizando los correspondientes a la Hacienda

Tributaria), que abarquen todas las tipologías (Informativos, Interactivos y Transaccionales).

Plan inicial La ejecución no podrá exceder 12 meses desde la

formación del equipo de trabajo. En cualquier caso los trabajos estarán finalizados a 31 de diciembre de 2007.

Fase I: transferencia de conocimiento al equipo de trabajo, análisis funcional, especificación y puesta en

marcha de la plataforma tecnológica necesaria para la generación y mantenimiento de aplicaciones interactivas

en TDT sobre el estándar MHP

Fase II: implantación de servicios informativos sobre la plataforma base de Televisión Digital

Fase III: ampliación de funcionalidades de la plataforma de Televisión Digital, habilitando el canal de retorno

(interactividad). Equipo de trabajo

Comité de dirección: dirección del proyecto, formado por

el responsable del Servicio de Promoción de la Sociedad de la Información, un responsable de NGA y el Jefe de

Proyecto en el Centro de Excelencia. Equipo de Trabajo: técnicos destinados al desarrollo del

proyecto:

1 persona del Servicio de Promoción de la Sociedad

de la Información que coordinará los contenidos a

incluir (dedicación 10%). 1 persona de NGA encargada de coordinar al equipo

y los trabajos realizados (dedicación 10%)

Responsable del Centro de Excelencia Java y Open

Source (dedicación 60%)

Becario del Centro de Excelencia Java y Open

Source con conocimientos de Java (dedicación 100%)

1 analista especializado en proyectos de desarrollos

de servicios TDT encargado de aportar su

experiencia y conocimiento (dedicación 50%)

1 ingeniero de desarrollo especialista en MHP

(dedicación 60%)

2 técnicos de empresas del sector TIC de Navarra,

con experiencia de 2 a 3 años en Java (dedicación 60%)

Planificación

Se elaborará un Plan de Trabajo que defina las tareas a

realizar, los responsables de su ejecución y los resultados

a obtener en cada caso. Se aportará también la secuencia y el cronograma de módulos o agrupación de

funcionalidades que se proponga seguir.

En cualquier caso existirá una 1ª Fase a finalizar a 30 de

abril de 2007, en cual estarán para poner en producción un mínimo de 2 de servicios en el ámbito de la Hacienda

Tributaria.

Tras leerlo mi primera impresión fue confusa: en la planificación

y en el alcance, dos aspectos muy delicados.

El título del proyecto sugería un alcance concreto: el desarrollo

de toda una plataforma que soportase los contenidos de la administración para la TDT. Sin embargo, el contenido del texto

vislumbraba otro alcance añadido: el desarrollo de un conjunto de servicios de la administración para TDT. Se trataba de

alcances y trabajos diferentes, una ambigüedad que presagiaba

dificultades a futuro.

Por otro lado, había dos planificaciones incoherentes entre si.

Una contemplaba 3 fases: una para formar, preparar el equipo y definir la plataforma, a continuación otra en la cual se

incorporaban a la plataforma servicios informativos y una última donde se incorporaban servicios interactivos. Un

planteamiento lógico y de dificultad gradual. Por el contrario,

luego se hablaba de otra planificación en 2 fases: una en la cual se desarrollaban los servicios para Hacienda (interactivos), y

una segunda aún por definir. Se empezaba por tanto por la parte más compleja y con el equipo probablemente sin

preparar. Sugería que la fecha de la campaña de la renta había comprometido el planteamiento inicial.

En esta situación, las 4 prioridades para la fase 1 parecían ser: identificación de los servicios para TDT de Hacienda, montaje

del equipo, plataforma de servicios TDT e identificación servicios para la fase 2. Esto es, una primera fase bastante

completa.

ASPECTO A MEJORAR: a futuro debe esclarecerse el

objetivo del proyecto, su alcance y las condiciones.

En cualquier caso, aún había muchas cosas por aclarar y

concretar. Por esa razón, durante el mes de diciembre se sucedieron una serie de reuniones en los CES, el centro de

operaciones de ese momento en adelante, de las cuales pueden

extraerse las siguientes informaciones útiles:

Limitaciones de la TDT:

Interfaz: se cuenta con un espacio muy reducido, además el aprovechamiento no es muy eficiente dado que debe

ser visible desde el sofá. Así mismo, el tele-espectador no tiene porque ser un usuario habituado a las tecnologías,

con lo que la navegación y uso de la aplicación debe ser lo más sencilla posible, guiando al tele-espectador en

todos los pasos. A todo esto hay que añadir el bilingüismo propio de la Comunidad Foral de Navarra y la guía de

estilos dewww.navarra.es con el fin de que se identifiquen los servicios con la marca del Gobierno de Navarra en la

web. Capacidad: tanto el ancho del banda del llamado carrusel

(donde se emiten las aplicaciones) en torno a 2Mbits

compartido, como la escasa capacidad de procesamiento y memoria del deco, obligan a tener mucho cuidado en el

peso de la aplicación. Existen varias implementaciones diferentes del estándar

MHP en el mercado, pero la preponderantes son dos,

Alticast y Osmosys, con lo que el comportamiento de las aplicaciones puede diferir de un deco a otro. Esto obliga a

realizar pruebas exhaustivas en una amplia batería de decos comerciales.

La llamada interactividad en la TDT no viene de “serie”,

sino que precisa de un canal de retorno a través de Internet por parte del deco bien por módem o bien por

ADSL.

Tratamiento de la información:

Se acuerda diseñar la aplicación de modo que la lógica esté desacoplada de la información de modo que esta

sean fácilmente modificable en emisión sin afectar a la funcionalidad. Esta información, consumida por la

aplicación, se presentará en forma de fichero XML, dada la estandarización de este formato.

Toda esta información se acuerda introducirla en la aplicación para su emisión de forma “manual”, sin llegar a

integrarlo en el gestor de contenidos. Esto queda fuera del alcance.

Así mismo, el intercambio de datos entre los servicios

sobre TDT y los sistemas de información del portal web se realizarán en base a servicios web. Aquí se quedó fuera

del tintero que ocurría si no existían esos servicios web, quién debía desarrollarlos.

Servicios a desarrollar:

Con información estática aún por determinar a modo de

teletexto. Con información dinámica (modificable en emisión) aún

por determinar pero priorizando los más demandados en www.navarra.es. (Ej: meteorología, farmacias, boletín,

carreteras, empleo, etc) Interactivos: servicios de Hacienda para la campaña de la

RENTA. Portal o lanzadera: se precisa de un menú que de acceso

a todos estos servicios del Gobierno de Navarra.

Servicios Hacienda:

Los dos servicios que más interés podían tener porque

habían funcionado a nivel nacional se descartaron: la “cita previa” era demasiado compleja y la “petición o

aceptación de borrador” no existía en Navarra. Por esa razón todo apuntaba a los siguientes dos servicios:

“Cuanto me sale a pagar o devolver” y “Cuando me devuelven”.

Estado del back-end: existen servicios web implementados y reutilizables por lo que tan solo faltaba

recibir sus especificaciones (XML) para verificar su

viabilidad e integración con TDT. Funcionalidad: el usuario se identifica mediante un DNI y

un PIN que le proporciona Hacienda. Plazos: La campaña de la RENTA comenzaba la segunda

quincena de Mayo, lo cual daba un poco más margen

respecto al hito inicial de Abril. Organización:

Reuniones semanales de la dirección del proyecto: NGA, DGpSI; CES y el asesor técnico.

Existirá una reunión de arranque con el comité entorno a Enero-Febrero y otra coincidente con la campaña de la

RENTA. El resto dependerá del Plan de Acción. Debía definirse un plan de comunicación al comité para

informar de los progresos, dificultades y decisiones pendientes que la dirección no podía tomar. Así mismo,

debía detallar los entregables de cada fase, perfiles, tareas, fechas y riesgos.

Las cosas empezaban a tomar forma pero aún había mucho por hacer. Por lo menos entonces teníamos claro lo que debía

hacerse para seguir avanzando y concretando puntos.

De entre todas esas tareas, puesto que el desarrollo para Hacienda (RENTA) era de lo más acuciante, tenía una absoluta

prioridad. Había que comenzar por aquí, además era lo más tangible y sólido de todo el proyecto.

No obstante, había otra serie de tareas también importantes que se pretendían acometer en paralelo:

Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección, contrato y transferencia de

conocimiento. Selección de los servicios a implementar durante la

segunda fase: reuniones con jefes de sección. Definición de la metodología y herramientas de trabajo.

Todo esto debería haberse contemplado dentro de un Plan de Acción, aún sin definir, que planificase todas las tareas antes de

entrar en acción, para lo cual se hubiera necesitado recopilar

algo de información previamente, no obstante, la premura de las cosas no lo permitió, todo iba sobre la marcha. La sensación

era que había demasiadas cosas a realizar, mucha urgencia, pocos recursos y bastante indeterminación.

Definición de la metodología y herramientas de trabajo

Como cualquier otro proyecto de software había unas herramientas básicas necesarias: un gestor de proyectos, un

sistema de control de versiones de código y una metodología.

Puesto que aún no contaba con equipo para poner en marcha

todo esto, debíamos salir adelante con lo que fuese. Casualmente, contábamos con una instalación de dotproject

para la gestión del proyecto y en última estancia con un CVS para el control de versiones de código (posteriormente

trabajaríamos con subversion). Esto era lo mínimo

imprescindible con lo que empezar. En cuanto a la metodología, se decidió asumir la que el asesor técnico sugiriese en estos

casos, lo cual también sería parte de esa transferencia tecnológica.

Así pues parecía estar todo, pero me surgía una duda, ¿necesitamos algo más para desarrollar aplicaciones para TDT?

La respuesta no estaba muy clara, así que se indagó y se elaboró un informe que contemplaba las necesidades hardware

y software. Este informe se publicó en ediciones anteriores del boletín (TDT: herramientas para desarrollo MHP (Parte

1) y TDT: herramientas para desarrollo MHP (Parte 2)). En resumidas cuentas, había que hacer una fuerte inversión en un

laboratorio de pruebas y en unas herramientas de desarrollo específicas para TDT. Las herramientas de desarrollo específicas

para TDT aunque facilitaban el diseño y el desarrollo no eran

estrictamente necesarias, y dado que se buscaba entre otras cosas una transferencia de conocimiento, se barajó no

emplearlas. No obstante, esto habría incidido en el ritmo de trabajo y dadas las circunstancias no era factible.

Esta decisión tomó largo tiempo en tomarse y unas cuantas conversaciones.

Selección de los servicios a implementar durante la segunda fase: reuniones con jefes de sección

Esta tarea requería sin lugar a dudas una intervención por parte de NGA y la DGpSI, por lo que, decidí delegar y depender de

ellos en este punto y concentrarme en otras tareas que recaían directamente en los CES.

Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección, contrato y transferencia de

conocimiento

Junto con el análisis de los servicios de la RENTA, la formación

del equipo parecía ser otra tarea muy urgente, debían estar

preparados para el desarrollo de la RENTA lo antes posible. Esta responsabilidad recaía en los CES.

Este fue el planteamiento tomado:

Es decir, la búsqueda del becario comenzó en cuanto se supo de esta necesidad en el proyecto. No obstante, la selección de

los profesionales exigía definir un perfil más específico, que

debía establecerse según los requerimientos del proyecto. Este no pudo establecerse hasta finales del 2007 cuanto ya se tenía

claro la experiencia y profesional buscado. En cualquier caso, se trató de un proceso contra-reloj, como se puede observar en la

planificación, con el fin de que el equipo estuviera listo a finales de enero y el proyecto pudiera arrancar con la primera reunión

del comité, teniendo aproximadamente un margen de un mes para recibir y seleccionar las candidaturas válidas.

Para lo cual, se establecieron unas bases de participación en el proyecto que incluían el perfil establecido y que se distribuyó de

diversas formas: prensa, mail electrónico y web. Cabe decir que algunos aspectos dieron lugar a ciertas confusiones,

probablemente por no estar suficientemente claras en las bases: fue el caso, por ejemplo, del objetivo de estas bases, se

buscaban empresas para participar en el desarrollo de un proyecto ya concedido, no para conceder el desarrollo del

proyecto a un tercero, número de candidaturas por empresa,

etc. En cualquier caso, tras la recepción de candidaturas se estableció un mecanismo por el cual se contrastaban con el

perfil buscado, descartando aquellas que no lo cumplían. Una

vez hecha esta criba quedaba decidir entre las que restaban, cuales participaban y cuáles no. Teníamos 3 candidatos válidos

técnicamente, decantarnos por uno u otro hubiera sido partidista. Con el fin de ser neutral, se decidió sacarlo a

suertes, aunque hubo cierto desacuerdo con este método.

Finalmente no hubo necesidad, puesto que una de las candidaturas abandonó el proceso por fuerza mayor. Esto puso

de manifiesto las carencias del sistema elegido que habría que pulir y corregir.

ASPECTO A MEJORAR: a futuro, para evitar estas ambigüedades, definir ámbito de las bases, tabular las

condiciones y emplear un proceso más objetivo.

Con el comienzo del año 2007, volvimos a reunirnos para seguir

atando cabos , retomar los trabajos y preparar la primera reunión del comité de Enero-Febrero. Las cosas no habían

cambiado mucho. Todo se centraba en preparar la reunión del comité, que era la presentación del arranque del proyecto, y

por tanto, los puntos en que había que trabajar:

Equipo de trabajo.

Plan de Acción.

Presupuesto inversiones para entorno de desarrollo y pruebas.

Estado servicios de la RENTA. Portal (lanzadera).

Propuesta de servicios a implementar.

Por tanto, seguíamos más o menos donde lo habíamos dejado. Las tareas del equipo de trabajo ya estaban lanzadas y se

habían detectado así mismo, las necesidades para el entorno de desarrollo y pruebas, tan solo quedaba ponerles “números”. No

obstante, los puntos más importantes que aún estaban abiertos y que eran claves: no habíamos avanzado en cuanto a la

propuesta de servicios puesto que antes debíamos reunirnos con las personas indicadas en Gobierno de Navarra, tampoco

estaba definido el Plan de Acción dentro del cual debían

enmarcarse la propuesta de servicios, el análisis de los servicios de la RENTA, y la definición del portal (lanzadera).

Así pues, el mes de enero resultó bastante “movido”, centrándonos en elaborar ese Plan de Acción y en recopilar

información para poder llevarlo a acabo: análisis de los servicios de RENTA, definición de la Lanzadera y selección de

los siguientes servicios.

El caso es que, como se puede observar, dada la premura, la

definición empezaba a diluirse con la primera fase de ejecución.

No obstante, estas andaduras se comentarán en el próximo

artículo.

Catego

rías

CES OpenSouce/Java

Tema

Varios

Autor

Raúl Sanz de Acedo

Mes Septiembre

Año 2008

Boletín

09

Título Configuración de Subversion

Texto Tras haber escrito un artículo de introducción a Subversion y otro explicando su instalación, a continuación

se explicará cómo configurarlo de tal forma que se pueda empezar a usar.

La distribución de Subversion incluye un cliente remoto

(svn), un servidor (svnserve), y varias utilidades. Se comenzará explicando cómo configurar el acceso a los

repositorios a través de Apache. Para ello se supondrá que ya existe un repositorio creado y que se ha modificado

httpd.conf para reflejar la configuración existente en la máquina antes de configurar el acceso a Subversion. Si no

se ha creado ningún tipo de repositorio, se podrá crear mediante el uso de la herramienta svnadmin. La

instrucción que se debería ejecutar sería:

svnadmin create /ruta/al/repositorio/NombreRepositorio

o si se quiere elegir el tipo de almacenamiento del mismo:

# Para crear un repositorio basado en FSFS

svnadmin create --fs-type fsfs /ruta/al/repositorio/NombreRepositorio

# Para crear un repositorio basado en Berkeley-DB

svnadmin create --fs-type bdb /ruta/al/repositorio/NombreRepositorio

Una vez que se tienen perfectamente configurados apache

y creados los repositorios necesarios, lo primero que httpd.conf debe hacer es cargar el módulo mod_dav_svn

que se instaló. Para ello debe existir la línea:

LoadModule dav_svn_module modules/mod_dav_svn.so

y debe ir por debajo de:

LoadModule dav_module modules/mod_dav.so

si no, se producirá un error.

Para dar acceso al repositorio se necesitará añadir al final del archivo httpd.conf o en un archivo .conf separado que

esté situado en un directorio en el que el servidor sea capaz de encontrarlo y cargarlo.

<Location /svnRepos>

DAV svn

SVNPath /ruta/absoluta/al/repositorio

</Location>

Esto dará un acceso sin restricciones al repositorio a

cualquiera que acceda a http://URLServidorConSubversion/svnRepos. Para

limitar el acceso de escritura o lectura, se deben añadir las siguientes líneas al bloque de Location:

AuthType Basic

AuthName "Subversion repository"

AuthUserFile /ruta/a/archivo/de/contraseñas

y además si:

El repositorio tiene restringido el acceso de

lectura/escritura:

Require valid-user

Para un repositorio con acceso de escritura limitado:

<LimitExcept GET PROPFIND OPTIONS REPORT>

Require valid-user

</LimitExcept>

Para restringir de forma diferente el acceso a lectura y escritura:

AuthGroupFile /my/svn/group/file

<LimitExcept GET PROPFIND OPTIONS REPORT>

Require group svn_committers

</LimitExcept>

<Limit GET PROPFIND OPTIONS REPORT>

Require group svn_committers

Require group svn_readers

</Limit>

Para crear el fichero de contraseñas se utilizará el comando de apache htpasswd. Lo que hace es con la opción –c crea

un archivo con las contraseñas en la ruta especificada. Con la opción –m, usa encriptación MD5 en

las contraseñas, que es más segura que la que usa por

defecto. Así un ejemplo de cómo crear un archivo de contraseñas sería el siguiente:

### Primera vez: use -c para crear el archivo

### Use -m para usar encriptación MD5 de la contraseña, que es más segura

htpasswd -cm /ruta/a/archivo/de/contraseñas harry

New password: *****

Re-type new password: *****

Adding password for user harry

### Como el archivo ya está creado, no se vuelve a

usar la opción -c

htpasswd -m /ruta/a/archivo/de/contraseñas sally

New password: *******

Re-type new password: *******

Adding password for user sally

Si en vez de apuntar a un único repositorio se quiere apuntar a varios que están contenidos en un mismo

directorio en vez de usar SVNPath, se puede emplear la instrucción SVNParentPath. Es decir:

<Location /svnRepos>

DAV svn

SVNParentPath /ruta/absoluta/al/directorio/con/repositorios

</Location>

Esto dará un acceso sin restricciones a todos los

repositorios incluidos en esa carpeta. Para acceder a ellos habrá que usar la siguiente

URL:http://URLServidorConSubversion/svnRepos/NombreRepositorio.

Apache también permite otras formas de autentificación

como la de tipo Digest, que se basa en autentificar al usuario mediante una contraseña que en vez de enviarse

sin encriptar, usa encriptación MD5. Para ello habría que emplear:

<Location /dominioDeDigest >

DAV svn

SVNParentPath /ruta/absoluta/al/directorio/con/repositorios

AuthType Digest

AuthName "Subversion repository"

AuthDigestDomain /dominioDeDigest/

AuthUserFile /ruta/a/archivo/de/contraseñas

Require valid-user

</Location>

En este caso además habría que cargar el módulo

mod_auth_digest y para crear los usuarios, en vez de emplear la utilidad htpasswd de apache habría que emplear

la htdigest. El problema que puede existir es que es un módulo todavía experimental y que no se ha probado

completamente, así que puede tener fallos. Para crear el archivo, entonces emplearíamos:

### Primera vez: use -c para crear el archivo

htdigest -c /ruta/a/archivo/de/contraseñas

/dominioDeDigest/ harry

New password: *****

Re-type new password: *****

Adding password for user harry

htdigest /ruta/a/archivo/de/contraseñas

/dominioDeDigest/ sally

New password: *******

Re-type new password: *******

Adding password for user sally

Si se quiere tener un control más estricto de la

comunicación se puede emplear conexiones seguras mediante SSL. Esto implica tener instalado OpenSSL para

poder cargar el módulo correspondiente en apache y también tenerlo instalado en la máquina cliente. Habría

que crear un certificado en el servidor y otro en el cliente. En este caso para acceder a Subversion se

utilizaría: https://URLServidorConSubversion/svnRepos/NombreRepositorio

Otras opciones que permiten un control más fino en el

repositorio se basan en el uso del módulo mod_dav_auth además del mod_dav_svn y el mod_dav necesarios

anteriormente, un fichero de contraseñas y un fichero de grupos y/o usuarios. En este último fichero se especificará

a qué partes del repositorio tiene acceso cada uno de los usuarios/grupos. Es decir, podrá haber partes de un

repositorio a las que no podrá acceder nadie más que unas

personas determinadas, otras en las que sólo se podrá leer y otras en las que se podrá leer y escribir. El problema

que tiene este tipo de autentificación es que el repositorio

tardará más en responder a las peticiones porque primero

deberá comprobar si el usuario que la ha solicitado tiene permiso para hacerlo. Así, para tener acceso que exija

autentificación la directiva Location debería tener este aspecto:

<Location /svnRepos>

DAV svn

SVNParentPath /var/svn

# our access control policy

AuthzSVNAccessFile /path/to/access/file

# only authenticated users may access the repository

Require valid-user

# how to authenticate a user

AuthType Basic

AuthName "Subversion repository"

AuthUserFile /path/to/users/file

</Location>

Si se quiere tener una mezcla entre acceso anónimo y

autentificado, entonces debería ser similar a:

<Location /svnRepos>

DAV svn

SVNParentPath /var/svn

# our access control policy

AuthzSVNAccessFile /path/to/access/file

# try anonymous access first, resort to real

# authentication if necessary.

Satisfy Any

Require valid-user

# how to authenticate a user

AuthType Basic

AuthName "Subversion repository"

AuthUserFile /path/to/users/file

</Location>

El aspecto que debería tener el archivo que restringe el acceso a los directorios del repositorio

(AuthzSVNAccessFile) debería ser:

# Se indica que CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com es

harry, para simplificar las cosas en el archivo.

[aliases]

harry = CN = Harold Hacker, OU = Engineers, DC = red-bean, DC = com

#Se definen los grupos, como harry es un alias, debe ir precedido por &

[groups]

calc-developers = &harry, sally, joe

paint-developers = frank, sally, jane

everyone = &harry, sally, joe, frank, sally, jane

# Con las siguientes 2 líneas se da acceso de lectura a cualquier usuario en todos los repositorios y en

todas las carpetas, porque todos los repositorios lo cumplen. Si no se especifican restricciones por

carpeta, entonces podrá leer en cualquiera de ellas cualquier usuario

[/]

* = r

# En las siguientes líneas, se restringe el acceso al

directorio branches/calc/bug-142 del repositorio calc. Se dan permisos de lectura y escritura a harry,

a jane sólo de lectura, y se niega explícitamente el acceso de lectura y escritura a joe al no añadir nada

tras el igual.

[calc:/branches/calc/bug-142]

&harry = rw

sally = r

joe =

# Dentro de la carpeta projects/calc, del repositorio calc, el grupo calc-developers tendrá acceso de

lectura y escritura, el resto de grupos o usuarios no

tendrá ningún permiso por no estar indicados.

[calc:/projects/calc]

@calc-developers = rw

# Dentro de la carpeta /projects/paint del repositorio

paint jane, a pesar de pertenecer al grupo paint-developers sólo podrá leer porque es más restrictivo,

y el grupo paint-developers (salvo jane) podrá escribir y leer.

[paint:/projects/paint]

jane = r

@paint-developers = rw

Este ejemplo ilustra varias cosas, desde el uso de grupos, de alias y el acceso a ciertas partes del repositorio. En

principio, se tomará la regla más restrictiva por la carpeta que se solicite.

Subversion también permite mostrar una lista de los

repositorios que se encuentran en el directorio al que apunta la directiva SVNParentPath de los ficheros de

configuración de Apache. En principio, esta opción permanece deshabilitada por motivos de seguridad. Si se

quiere habilitar habría que añadir la siguiente línea a la directiva Location:

SVNListParentPath on

Esta opción no termina de funcionar correctamente. Para

poder mostrar los repositorios y que funcione, lo que se debe hacer es además de añadirla dentro de la directiva

Location, añadir un / al final del nombre al que apunta Location, de esta manera nos quedaría la directiva Location

así:

<Location /svnRepos/>

DAV svn

SVNParentPath

/ruta/absoluta/al/directorio/con/repositorios

SVNListParentPath on

</Location>

Se podrían añadir todas las opciones que fueran

necesarias. Para ver la lista de repositorios que hay en el servidor, entonces se iría

a:http://URLServidorConSubversion/svnRepos/ . Es muy importante añadir la última barra, porque si no, no los

mostrará y dará un error.

Si en vez de usar Apache como servidor de Subversion, se emplea „svnserve‟, entonces para invocarlo se puede hacer

de diferentes formas:

En sistemas basados en UNIX como Linux, se puece hacer que svnserve corra como demonio escuchando

las peticiones.

Hacer que el demonio inetd de Linux/UNIX/Solaris lance temporalmente svnserve cada vez que una

petición llegue por un cierto puerto.

Hacer que SSH invoque un svnserve temporal sobre un túnel encriptado.

Ejecutar svnserve como un servicio de Microsoft

Windows.

Para lanzar svnserve como demonio, entonces habrá que

ejecutar:

svnserve –d

Si además se quiere aumentar la seguridad, se puede pasar la opción –r seguida de una ruta, que restringirá los

repositorios a los que se puede acceder a aquellos que estén en subdirectorios de la misma.

Para que sea inetd el que invoque a svnserve, se debe

lanzar svnserve con la opción –i, pero además habrá que comprobar que en el fichero /etc/services existan las

entradas referidas a Subversion:

svn 3690/tcp # Subversion

svn 3690/udp # Subversion

Además habría que añadir la siguiente línea al fichero

inetd:

svn stream tcp nowait svnowner /usr/bin/svnserve svnserve -i

donde svnowner es un usuario que debe tener permisos de

lectura y escritura sobre el repositorio, se puede cambiar a otro que los tenga.

En el caso de que sea SSH el que invoque a svnserve, entonces lo hará con la opción –t.

En el caso de querer ejecutarlo en Windows, entonces

habrá que ejecutar una vez:

sc create svn

binpath= "C:\directorio\instalacion\Subversion\bin\svnserve.ex

e --service -r C:\directorio\repositorio"

displayname= "Subversion Server"

depend= Tcpip

start= auto

Con esto se ejecutará cada vez que se lance Windows el

servicio svnserve. No puede ejecutarse con opciones como –d, -t o –i porque entra en conflicto.

Si se quiere modificar la forma de acceder al repositorio a

través de svnserve, habrá que modificar el archivo svnserve.conf. En este se especificará el tipo de acceso

que se deja, como se puede ver en los siguientes ejemplos:

[general]

password-db = ArchivoDeContraseñas

realm = dominio_de_ejemplo

# Los usuarios anónimos solo pueden leer el repositorio

anon-access = read

# Los usuarios autentificados pueden leer y escribir

auth-access = write

En este caso se ha permitido acceso de lectura a usuarios

anónimos y de lectura y escritura a todos los usuarios, es como viene por defecto. En el siguiente el acceso será más

conservador y sólo se permitirá que accedan si se autentifican.

[general]

password-db = ArchivoDeContraseñas

realm = dominio_de_ejemplo

# No se permiten usuarios anónimos

anon-access = none

# Los usuarios autentificados pueden leer y escribir

auth-access = write

El proceso servidor entiende no sólo estos controles de

acceso al servidor si no también controles más finos definidos en archivos de acceso como el explicado en el

caso de Apache como servidor de Subversion. Para ello se necesita un archivo con las reglas más detalladas y que la

variable authz-db la señale.

[general]

password-db = ArchivoDeContraseñas

realm = dominio_de_ejemplo

# Reglas de acceso específicas para localizaciones

específicas

authz-db = ArchivoDeReglasDeAcceso

Además, la opción authz-db, anon-access y auth-access no se excluyen por lo que si se incluyen las tres, sólo los

usuarios que las cumplan podrán acceder al repositorio.

Para hacer estas autentificaciones, svnserve trae por defecto implementado MD5, pero si durante la instalación

de Subversion tanto en el lado del cliente como en el del servidor se instaló SASL, esto permitirá mayores opciones

para la comunicación entre ambos.

Para obtener más información sobre el tema, se pueden

consultar la documentación siguiente:

ENLACES DE INTERÉS:

Subversion

http://en.wikipedia.org/wiki/Subversion_(software)

http://es.wikipedia.org/wiki/Subversion

http://subversion.tigris.org/

http://www.1x4x9.info/files/subversion/html/online-chunked/index.html

http://svn.collab.net/repos/svn/trunk/INSTALL

Version Control with Subversion, Ben Collins-

Sussman, Brian W. Fitzpatrick, C. Michael Pilato. -> http://svnbook.red-bean.com/

Categorías

CES OpenSouce/Java

Tema Varios

Autor Blanca Cubas

Mes Septiembre

Año 2008

Boletín 09

Título Técnicas de mapeado de texturas. Parte 1

Texto Para la implementación de shaders que es en lo que me

encuentro inmersa en este momento, y sobre lo que ya traté

brevemente en un artículo anterior, es muy común la

utilización de distintas técnicas de mapeado de texturas. Su

ventaja es que, sin consumir muchos recursos gráficos, nos

permiten obtener efectos complejos y bastante realistas de

manera sencilla.

Como introducción al tema, decir que un mapeado de textura

sencillo consiste en indicar la correspondencia entre los

vértices de un objeto 3D (x,y,z) y las coordenadas de una

textura (u,v), tal y como se ve en la siguiente figura:

Sin embargo, si queremos conseguir mayor nivel de realismo,

tendríamos que utilizar otro tipo de técnicas más avanzadas.

Algunas de las más utilizadas son las siguientes:

Bump Mapping. Normal Mapping.

Displacement Mapping. Parallax Mapping.

Debido a la complejidad de las mismas, en este primer

artículo nos vamos a centrar en las dos primeras técnicas. Ambas, tienen como objetivo dar aspecto de

relieve a un objeto, a partir de una textura que modifica

sus normales sin cambiar la geometría del mismo: es decir, modificamos la representación del “material” del

objeto pero no su estructura 3D. La única diferencia que existe entre una técnica y otra es

la textura de normales que utilizamos en cada caso.

Bump Mapping NormalMapping

Bump Mapping

Las texturas que se emplean para realizar Bump Mapping son

texturas en escala de grises que únicamente nos dan el valor

de la altura. Los valores más próximos al negro se convierten

en protuberancias y los más cercanos al blanco en

hendiduras. Con ello lo que hacemos es “falsear”

desplazamientos arriba y abajo de la verdadera superficie.

Normal Mapping

Las texturas que se emplean para realizar Normal Mapping

son texturas RGB que a través de sus distintos canales, nos

dan información sobre los ejes x, y, z. La componente azul, es

la que más nos interesa en este caso, ya que es la que nos da

la información sobre el relieve de la textura.

La mejor forma de ver el resultado que tienen estas técnicas

es a través de un ejemplo práctico. Para ello hemos

implementado el siguiente código enNvidia FX Composer 2:

//Lo primero que hacemos es definir las matrices de transformación y los

parámetros a //utilizar por defecto.

float4x4 WorldITXf : WorldInverseTranspose < string UIWidget="None"; >;

float4x4 WvpXf : WorldViewProjection < string UIWidget="None"; >;

float4x4 WorldXf : World < string UIWidget="None"; >;

float4x4 ViewIXf : ViewInverse < string UIWidget="None"; >;

float Timer : Time < string UIWidget = "none"; >;

float4 lightPos = (1.0f,1.0f,1.0f,1.0f);

//A continuación definimos las texturas que vamos a utilizar. La primera

se trata de la //textura (u,v), que vamos a aplicar a nuestro objeto, en

este caso, un plano.

texture WallTexture <

string ResourceName = "rockwall.jpg”;

string UIName = "WallTexture";

string ResourceType = "2D";

>;

sampler2D WallSampler = sampler_state {

Texture = <WallTexture>;

};

//Y la segunda se trata de la textura que se utiliza para almacenar la

información de //las normales.

texture NormalTexture <

string ResourceName = "rockwall.tga";

string UIName = "Normal Map";

string ResourceType = "2D";

>;

sampler2D NormalSampler = sampler_state {

Texture = <NormalTexture>;

};

//Vertex Shader

// Necesitaremos la normal, binormal y tangente para poder situar la

textura en el //espacio 3D, porque la función tex2D no tiene eso en

cuenta. Para transformar los //vectores luz y posición se emplean la

normal, binormal y tangente, que forman un //espacio de coordenadas

propio (una matriz) que al multiplicarla nos dará los vectores //luz y

posición en ese espacio de coordenadas.

void mainVS(float4 Position : POSITION0,

float3 Normal : NORMAL,

float3 tangent : TANGENT,

float3 binormal : BINORMAL,

float2 TexCoord : TEXCOORD0,

out float4 oPosition : POSITION0,

out float2 oTexCoord : TEXCOORD0,

out float2 oNormalCoord : TEXCOORD1,

out float3 lightVec : TEXCOORD2,

out float att : TEXCOORD3)

{

oPosition = mul(Position, WvpXf); //

float4 posWorld = mul(Position, WorldXf); // Posición del vértice

en el mundo 3D

float3 light = normalize(lightPos - posWorld); //Obtenemos la luz en

cada vértice

float3x3 TBNMatrix = float3x3(tangent, binormal , Normal);

lightVec = mul(TBNMatrix, light);

att = 1/( 1 + ( 0.005 * distance(lightPos.xyz, posWorld)

) );//calculamos la atenuación de la luz

oTexCoord = TexCoord;

oNormalCoord = TexCoord;

}

//PixelShader

// Tendremos que pasar los vectores luz y posición transformados al

pixel shader que //los usará igual que hasta ahora para generar el

componente difuso y especular.

void mainPS (float4 oPosition : POSITION0,

float2 oTexCoord : TEXCOORD0,

float2 oNormalCoord : TEXCOORD,

float3 lightVec : TEXCOORD2,

float att : TEXCOORD3,

out float4 oColor : COLOR)

{

float4 color = tex2D(WallSampler, oTexCoord); //Calculamos el color

de la textura en cada punto

//La normal se extrae del nuestra textura NormalTexture de la siguiente

manera:

float3 normal = 2.0f * tex2D(NormalSampler, oNormalCoord).rgb -

1.0f;

float3 light = normalize(lightVec); //Normalizamos el valor de la

luz

float diffuse = saturate(dot(normal, light)); //Calculamos el color

difuso

oColor = att * color * diffuse; //Obtenemos el color final

}

//Y aplicamos la técnica deseada

technique Main

{

pass p0

{

VertexShader = compile vs_3_0 mainVS();

PixelShader = compile ps_3_0 mainPS();

}

}

La imagen de la izquierda se corresponde con un mapeado de

textura básico, y la de la derecha aplica dicha textura junto

con un Normal Mapping.

Comentar como aspecto interesante, que las texturas de

normales se puede crear con el plugin para Photoshop de

NVidia, o con el programa CrazyBumpentre otros.

Categorías CES Microsoft

Tema Desarrollo

Autor Goretti Ortigosa Rada

Mes Septiembre

Año 2008

Boletín 09

Título Registro (Logging) en aplicaciones .NET

Texto En la pasada edición de la NavarParty, que contó con una muy buena asistencia,

tuve la oportunidad de asistir a una charla presentada por Iván Gonzalez,

de PlainConcepts, que trató sobre el registro de eventos en aplicaciones .NET.

Iván demostró ser no sólo un muy buen comunicador y un profesional con

muchos conocimientos, sino además alguien que se esfuerza por ello como

aquellos que conocen en periplo ferroviario que Iván realizó para venir a dar esa

charla pueden atestiguar. Como sencillo reconocimiento aquí pongo una foto de

Iván en acción:

El tema de la charla me recordó que en alguna parte había visto algo al respecto

y me acordé de un articulito breve de Scott Mitchell (MVP desde 2002, gurú de

ASP.NET, creador de4gyusfromrolla.net… en definitiva, todo un IT) sobre un

tema muy similar. En él se presentan un par de herramientas que vienen a cubrir

lo presentado por Iván en cuanto a registro de eventos:

- Enterprise Library 4.0: http://msdn.microsoft.com/en-us/library/cc512464.aspx

- Log4net: http://logging.apache.org/log4net/index.html

Ambas son herramientas OpenSource, siendo la segunda de ellas obra de la

Apache Software Foundation como una versión de su log4j, la librería para

registro de eventos en aplicaciones Java, mientras que la primera es creación del

grupo de Microsoft “Patterns & Practices”.

¿Cuál es el beneficio de usar estas librerías? O más sencillamente, ¿por qué

deberíamos molestarnos en usarlas? Estas librerías tienen como objetivo facilitar

en registro de eventos en aplicaciones de escritorio hechas en .NET. Hoy en día

los desarrollos de software disponen de una serie de herramientas, marcos de

desarrollo (frameworks), librerías, etc. que permiten que las aplicaciones en

general sirvan para el cometido para el que se han diseñado de manera

aceptable. La calidad en el desarrollo de software sin embargo se encuentra

ahora en otras áreas: zonas como el control de rendimiento y errores ocultos así

como la trazabilidad de accesos y auditoría son elementos que hoy en día se

demandan por parte de los compradores de software. Y es aquí donde el

beneficio de este tipo de librerías se aprecia al máximo. Porque si bien

anteriormente este registro de eventos se podía hacer de una manera artesanal

y era aceptable (quién no recuerda pasar horas con el bloc de notas buscando

mensajes específicos en ficheros planos de texto para poder explicar qué había

pasado en un programa…) hoy nos encontramos con que la gran mayoría de

fabricantes de software empresarial disponen en su catálogo de herramientas de

control y monitorización de sistemas automatizadas (IBM, MS, Oracle…) que

simplifican enormemente la vida a los administradores de sistemas y por tanto

van a querer que nuestro software utilice cuanto antes. Y a nosotros como

desarrolladores nos va a facilitar tareas como el traceado de nuestras

aplicaciones, análisis de errores, mejoras en rendimientos, y otras como la

distribución de aplicaciones (nos evitaremos errores por configuración errónea

de los contenedores de estos registros), etc.

La Enterprise Library es un conjunto de bloques de aplicación, que se definen

como un conjunto de clases, cada uno diseñado para una tarea de desarrollo

específica, como:

- Registro

- Acceso a datos - Gestión de excepciones - …

El que nos interesa es el Bloque de Aplicación de Registro (Logging Application

Block) que nos facilitará este registro de eventos. Antes de utilizarlo, deberemos

configurarlo e indicar qué monitores de traza (trace listeners) vamos a emplear.

Un monitor de traza es el objeto que se encargará de recoger la información que

nos interesa y escribirla en un almacén de registro específico. La Enterprise

Library tiene varios monitores predefinidos que pueden escribir la información

en el Registro de Sucesos de Windows (Event Log), en una base de datos, en un

fichero de texto, un mensaje de email, etc. También se nos permite crear

nosotros mismos otros monitores para escribir en otras fuentes.

La configuración del Bloque de Aplicación de Registro también incluye

categorías, filtros y formato de los registros. Las categorías nos permiten la

clasificación de los registros, por ejemplo: “Errores de acceso a datos” o

“Mensajes de Debug”. Cada registro pertenecerá a una categoría, y tendrá

también una serie de propiedades como prioridad o severidad. Mediante el uso

de diversos filtros basados en las categorías y propiedades de los mensajes de

registro podremos ajustar el comportamiento del registro de eventos en

distintos entornos: por ejemplo, en un entorno de pruebas podemos

interesarnos por todos los mensajes de prioridad 5 o más, o bien en un entorno

de producción podemos querer omitir todos los mensajes de la categoría

“Mensajes de Debug”. Por último, el formato de los registros nos permitirá

definir el formato que usaremos para almacenar la información en los mensajes.

Una vez hecho esto, tendremos que hacer uso en nuestros desarrollos de la API

del bloque de aplicación de Registro de manera que creemos eventos en

nuestros programas. Esto será tan sencillo como por ejemplo crear un objeto de

tipo LogEntry en la parte Catch de una excepción, recoger en este objeto los

detalles de la excepción mediante sus propiedades y finalmente registrar el

evento mediante una llamada al método Write de la clase que representa el

motor de registro enviándole como parámetro el objeto LogEntry. Esto generará

que el Bloque de Aplicación de Registro evalúe la entrada contra los filtros

definidos previamente y las categorías, determine si debe almacenarse y en caso

positivo le aplique el formato adecuado antes de registrarlo.

Por ejemplo, en el blog de Tercer Planeta nos mostraban el siguiente código

(sobre la versión 3.0 de la Enterprise Library, pero vale igualmente para 4.0)

public void EjecutarTarea(Tarea tarea)

{

try

{

Logger.Write("Preparando la tarea " +

tarea.Descripcion);

tarea.Preparar();

Logger.Write("Ejecutando la tarea " +

tarea.Descripcion);

tarea.Ejecutar();

Logger.Write(string.Format("Resultado de la Tarea (0):

{1}",

tarea.Nombre, tarea.InfoResultado));

}

catch (Exception ex)

{

Exception outEx;

if (ExecutionPolicy.HandleException(ex, "TareasP

olicy", out outEx))

throw outEx ?? ex;

}

finally

{

Logger.Write(tarea.Descripcion + " Finalizada");

}

}

Por su parte log4net emplea una aproximación similar (algunos elementos

cambian de nombre, como los “appenders” en vez de los monitores de traza, o

los “layouts” en vez de las reglas de formato) y proporciona los mismos

resultados. Por defecto incluye más posibles destinos para el registro, como

fuentes de datos ADO.NET, la traza ASP.NET, la ventana de consola, un buffer en

memoria, etc. Lo que sí aporta log4net es la posibilidad de emplear una jerarquía

de registros, de manera que se puede definir niveles para los registros (por

ejemplo DEBUG, INFO, WARN y FATAL) que permiten clasificar de manera simple

los niveles de los registros que se crean y que pueden usarse para establecer que

un determinado appender responda sólo a los mensajes de un nivel concreto.

En definitiva, dos librerías que merece la pena considerar si hemos decidido dar

dos cosas:

- Dotar a nuestras aplicaciones de calidad en todos sus extremos. - Sufrir menos en nuestro trabajo, usando herramientas que nos

simplifiquen tareas y sobre todo que nos permitan apagar fuegos más rápido.

Categorías

CES Microsoft

Tema Desarrollo

Autor Rafael Flores Yoldi

Mes Septiembre

Año 2008

Boletín 09