Download - Cesnavarra 2008-boletín 9
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> </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>•</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>•</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