DOCUMENTACIÓN DE CONSIDERACIONES Y DISCUSIÓN SOBRE IMPLEMENTACIÓN DE LA IDE

Transcripción

1 SIPBAB Contenido 1 DOCUMENTACIÓN DE CONSIDERACIONES Y DISCUSIÓN SOBRE IMPLEMENTACIÓN DE LA IDE 1.1 líneas para el desarrollo, adaptación e implementación de sistemas geoespaciales 1.2 lineamientos tecnológicos geoespaciales 1.3 contextualización y justificación técnica 2 DOCUMENTACIÓN TÉCNICA 2.1 cassia: instalación en Debian Linux Pasos previos Embebiendo el jdbc en la webapp cassia Afinaciones tomcat para el nuevo jdbc Problema "Database Null" 2.2 georchestra instalación administración usuario 2.3 servidores en la infraestructura de desarrollo 3 MODELO DE DATOS 4 APUNTES Y REFERENCIAS DOCUMENTACIÓN DE CONSIDERACIONES Y DISCUSIÓN SOBRE IMPLEMENTACIÓN DE LA IDE líneas para el desarrollo, adaptación e implementación de sistemas geoespaciales Conforme con el pensamiento progresista del Estado Boliviano [1] el SIPBAB estará alineado con el Software Libre Todos los sistemas geoespaciales, incluyendo también sistemas operativos, los sistemas de infraestructura, los sistemas de administración, así como todos los softwares empleados a lo largo de todo el flujo de trabajo con geoinformación 1 of 65

2 desde su adquisición hasta su publicación (sistemas desktop y clientes SIG, por ejemplo) serán sistemas de Software Libre Es Software Libre todo aquel software cuya licencia garantiza las siguientes 4 libertades: Libertad para ejecutar el programa para cualquier propósito Libertad para estudiar como funciona el programa y adaptarlo a las necesidades propias. Por lo tanto, es imprescindible acceso al código fuente Libertad para redistribuir copias Libertad para perfeccionar el programa y liberar dichos perfeccionamientos, de modo que todos se beneficien. De aquí también es imprescindible acceso al código fuente De acuerdo al ARTÍCULO 77 (SOFTWARE LIBRE) de la LEY 164 (Ley General de Telecomunicaciones y Tecnologías de la Información y Comunicación): "I. Los Órganos Ejecutivo, Legislativo, Judicial y Electoral en todos sus niveles, promoverán y priorizarán la utilización del software libre y estándares abiertos, en el marco de la soberanía y seguridad nacional" De manera inseparable al anterior lineamiento, se manifiesta adhesión al principio de Estándares Abiertos, ya que ellos garantizan la interoperabilidad. La principal entidad en el mundo actualmente involucrada con los Estándares Abiertos para sistemas geoespaciales específicamente es la Open Geospatial Consortium (OGC) [2]. La OGC tiene como misión "conducir el desenvolvimiento global, la diseminación y la compatibilización de padrones abiertos y arquitecturas que viabilicen la integración de datos geográficos y servicios con diversas aplicaciones". Al tratarse de estándares ampliamente diseminados y observados, la OGC trabaja plenamente integrada y coordinada con la International Standards Organization (ISO) Particularizando el anterior principio, el componente Infraestructura de Datos Espaciales (IDE) debería orientarse a las siguientes líneas, en principio: Permitir la búsqueda, hallazgo, visualización, descarga de datos y consumo de servicios espaciales Consolidar la conexión permanente entre geodatos y metadatos Cumplir con una estricta observancia a estándares Como ejemplo, algunas de las directrices IDE de la INSPIRE [3] son las siguientes: Los geodatos deben ser colectados sólo una vez y resguardados donde puedan ser mantenidos efectivamente 2 of 65

3 Debe ser posible combinar llanamente información espacial de diferentes fuentes y compartirla con varios diferentes usuarios y aplicaciones Debe ser posible para información colectada a determinado nivel/escala el ser compartida a todos los niveles/escalas: en detalle para investigación, general para propósitos estratégicos La geoinformación es necesaria para una buena gobernanza a todos los niveles en las instituciones, y debe estar presta y transparentemente disponible Debe proveerse facilidad para encontrar geodatos disponibles, para el uso de éstos para satisfacer necesidades, y para que se conozca bajo qué condiciones éstos pueden ser adquiridos y usados Es claro que las implicaciones de los lineamientos aquí propuestos no se restringen al tema técnico y tecnológico, sino que manifiestan de hecho posiciones y compromisos organizacionales muy explícitos y bien definidos. Su alcance, por lo tanto, rebasa el ámbito técnico informático y/o geográfico, llegando a lo institucional. lineamientos tecnológicos geoespaciales A continuación se detallan las soluciones técnicas implementadas (todas ellas en estricta conformidad con los anteriores lineamientos) en conjunto con la necesidad técnica principal que cada una satisface: Almacenamiento de geodatos: postgresql/postgis Directorio de usuarios: openldap Solución IDE: framework georchestra Motor proveedor de geoservicios: geoserver Catálogo de metadatos: geonetwork Visualizador avanzado: mapfishapp Infraestructura para la publicación en web: Servlet container: Tomcat Proxying: Apache Auxiliares para la administración de servidor vía web: Tareas de administración y mantenimiento de servidor: webmin Shell del servidor en browser: shellinabox Tareas de administración del servlet container: tomcat manager Administración y mantenimiento del RDBMS: phppgadmin Administración y mantenimiento del directorio: phpldapadmin Sistema operativo de servidor: Debian gnu/linux "Squeeze" Código fuente y compilación: git, jenkins CI Virtualización: Virtualbox OSE sobre contenedores vmdk A continuación se enumeran los estándares geoespaciales OGC cuyo cumplimiento está plenamente logrado, en particular con las herramientas framework georchestra y posgresql/postgis: 3 of 65

4 Web Map Service [4] Web Feature Service [5] Web Map Tile Service [6] Web Map Context [7] Styled Layer Descriptor [8] Catalog Service Web [9] Simple Features Specification for SQL contextualización y justificación técnica Los siguientes aspectos han pesado de manera determinante en diversas decisiones técnicas efectuadas en esta consultoría: se trabajó con equipos y recursos prestados por geobolivia los meses de octubre y noviembre. Ello ha implicado rehacer los trabajos desde cero varias veces cesada ya la ayuda de geobolivia, recursos mínimos para trabajo de desarrollo (equipos para personal y servidores de desarrollo; internet de adecuada performance) fueron provistos a finales de diciembre [10] desde fines de diciembre hasta el final de la consultoría, todo el equipamiento físico provisto para el componente IDE y las aplicaciones BIOCAN fueron una laptop y un equipo pc [11] en ambiente de desarrollo. no ha existido nunca hasta el final de la consultoría un ambiente de producción con condiciones mínimas para el componente IDE [12] hasta el final de la consultoría no se contó con nombre de dominio [13] todas las bases de datos de los sistemas BIOCAN suministradas para su migración al SIPBAB adolecen de una falla de seguridad mayor [14] Como consecuencias directa de los anteriores factores, han debido tomarse las siguientes decisiones técnicas: Debido al factor 5: La versión final del componente IDE (framework georchestra) ha sido generada bajo un nombre local cualquiera (vm-georchestra) y NO bajo el nombre de dominio necesario para la web, y por lo tanto tiene funcionalidad completa solamente en equipos que se configuren específicamente para resolver dicho nombre de dominio El módulo extractorapp no fue implementado El módulo editor no fue configurado Debido a los factores 3 y 4: La infraestructura de servidores virtuales funciona basada en la solución de 4 of 65

5 virtualización ligera virtualbox OSE con contenedores vmdk, par aceptable para condiciones de desarrollo pero no de producción Se ha optado por usar Linux appliances Turnkey Linux en lugar de Debian Linux genérico [15] Debido al factor 6: Se ha optado por manejar dos instalaciones diferentes de postgresql [16] con el motivo de mantener a la base de datos con el riesgo de seguridad separada de la base de datos segura. DOCUMENTACIÓN TÉCNICA cassia: instalación en Debian Linux Pese a tratarse de un servlet de java (y que, por lo tanto, debiera funcionar de manera idéntica independientemente del sistema operativo), esto no ha sido así, y en realidad la aplicación BioCAN cassia ha representado mucho esfuerzo de investigación y experimentación de parte del consultor para lograr su funcionamiento en SO Debian Linux, debido principalmente a la inexistencia total de documentación que no sea para Windows. Pasos previos En el presente trabajo, las aplicaciones biocan fueron desplegadas en su propio contenedor virtual, el cual se adjunta como producto [17] Primero deben seguirse las instrucciones de la wiki de cassia. El archivo datanucleus.properties debe buscarse especificando All Downloads 5 of 65

6 Ahora deben revisarse qué versiones de jdk se tiene: Igualmente para averiguar qué version de postgresql se tiene (la base de datos postgresql fué desplegada en su propio contenedor virtual, el cual se adjunta como producto [18] ): Con esa información, obtener el jdbc correcto en el sitio de jdbc para postgresql: 6 of 65

7 Por ejemplo, en nuestro caso se obtuvo el jdbc versión 4, recomendado para jdk 1.6 y postgresql 8.4 Embebiendo el jdbc en la webapp cassia Los archivos.war (como cassia) son en realidad una compresión zip de una estructura específica de archivos y directorios. Lo que debe hacerse ahora es: Descomprimir (con cualquier utilidad zip) el cassia.war Reemplazar el jar postgresql existente en /WEB-INF/lib por el jar ya descargado en el paso anterior Recomprimir todo como zip y renombrarlo cambiándole la extensión de zip a war Afinaciones tomcat para el nuevo jdbc 7 of 65

8 Considerando la localización preferida por tomcat para los archivos jdbc, generamos un enlace simbólico al nuevo jar de forma que se obtenga lo siguiente: Con el siguiente comando: Añadimos a continuación dicha localización al $CLASSPATH de tomcat en los lugares en los que se define dicha variable, de modo que las líneas pertinentes del archivo quedarían como sigue: 8 of 65

9 Problema "Database Null" Lo anterior resuelve el problema "Not suitable driver...", pero también se ha presentado un problema "Database Null...", problema nuevo y diferente al anterior. Este problema se presentó en una ocasión en que se empleó postgresql 9.1, y se ignora su causa real. El contexto es: Debian Wheezy, OpenJDK 6 y Postgreesql 9.1 En la interfaz web se obtuvo mensaje de error indicando "Database Null". En catalina.out podía verse el mensaje "java.lang nullpointerexception" (esto significa que existe una variable no instanciada, es decir con valor nulo). De ambos mensajes, se deduce que el valor de la dirección de la base de datos es el problema, y el único lugar en el que se define este valor es en el archivo datanucleus.properties. Nótese, sin embargo, que la versión empleada de cassia.war posee su propia versión del archivo, ligeramente diferente, en la ubicación cassia/web- INF/datanucleus.properties. Es este último archivo (en esta localización) que debe configurarse con la dirección de la base de datos para subasanar el problema "Database Null" georchestra instalación código fuente y compilación Git es un sistema distribuído de control de versionamiento. No precisa de un servidor central, permite acceso completo a todo el código fuente e historial, es 9 of 65

10 rápido, y es de los manejadores de versionamiento más sencillos que existen. Entre las ventajas de manejar el código fuente bajo versionamiento, pueden mencionarse las siguientes: el hecho de que se pueden preservar proyectos completos en estado funcional permite trabajar sin temor a pérdidas o daños accidentales. la posibilidad de generar nuevas ramificaciones del mismo proyecto permite el desarrollo en paralelo sin interferencias de, por ejemplo, código experimental sobre el código de producción. el trabajo concurrente y simultáneo de varios desarrolladores se facilita enormemente con el uso de una herramienta de versionamiento (más aun una herramienta distribuida de versionamiento, como git). De otro modo, cada desarrollador tendría que copiar, comparar e integrar sus propios cambios a mano. Es fundamental comprender que el código fuente de georchestra viene en varios submódulos, y que para una compilación exitosa, debe asegurarse que las modificaciones propias introducidas no son incompatibles con la versión de código fuente empleada, ni en el proyecto principal ni en los submódulos. El siguiente código instala lo necesario para la compilación y obtiene el código fuente del proyecto principal georchestra y sus submódulos # apt-get install ant openjdk-6-jdk # git clone --recursive Nótese que entre los productos entregados está el código fuente georchestra actualizado por última vez hacia finales de marzo 2013 [19], por lo tanto sólo se necesita actualizar este repositorio, no descargar nuevamente el repositorio completo. El flujo de trabajo empleado para el trabajo con el código fuente de georchestra ha sido básicamente el siguiente: Actualización del código fuente (git pull, git fetch) Fusión del código remoto con el código local (git merge) Resolución de conflictos si los hubiera (con herramientas diff: en este trabajo se ha empleado la herramienta vimdiff) Revisar siempre la no incompatibilidad de los cambios recientes con el proyecto principal y con los submódulos (git log, git show, git status). Esto normalmente es cuestión de "prueba y error" compilando el código fuente generado hasta su descarte o su éxito. Aquí es siempre de gran ayuda la revisión de los logs de compilación. Persistencia del código propio generado: 1. Si se tiene acceso al repositorio remoto, contribuir con el código propio (git push) 2. Independientemente de lo anterior, siempre es recomendable manejar el 10 of 65

11 código propio como una branch del repositorio git, independiente de las branches "oficiales", y efectuar todo el registro de versiones sobre esta branch (git add, git commit) Obviamente esto es una simplifación significativa, pues en la realidad el trabajo con versionamiento implica (por su propia naturaleza) innumerables posibles variaciones de dicha situación, y por lo tanto existen también muchos diferentes cursos de acción para resolver cualquier problema. De aquí que para poder compilar un georchestra personalizado son fundamentales comprensión y manejo sólido de la herramienta git Se ha seguido aproximadamente el flujo de trabajo básico indicado previamente para cada nueva actualización de código fuente, sea remoto o local (propio) hasta finales de marzo El último código fuente compilado se encuentra en el siguiente estado de versionamiento: Posicionados en el directorio raíz del repositorio: git status # Not currently on any branch. # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # (commit or discard the untracked or modified content in submodules) # # modified: config/configurations/template (modified content) # modified: geonetwork (modified content, untracked content) # modified: geoserver/geoserver-submodule (untracked content) # modified: mapfishapp/src/main/webapp/web-inf/ws-servlet.xml # modified: pom.xml # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # analytics/src/main/webapp/web-inf/analytics.properties # mapfishapp/src/main/webapp/contexts/ no changes added to commit (use "git add" and/or "git commit -a") Obsérvese que existen mensajes de git para los siguientes submódulos (en detalle junto con su respectivo commit): git submodule status d0d1bffe56a1750d359a8d54c71d71df397a8a config/configurations/template (74d0d1b)... +c7ea163e b412f4f000da56fa240f3677 geonetwork (remotes/origin/georchestra-26) +2eb cc73342a55d5a606592ff188763dc geoserver/geoserver-submodule ( g2eb0408) of 65

12 En este caso git está indicando que en los tres submódulos existe contenido modificado (en comparación a lo versionado) así como también existe contenido no seguido (no versionado). El detalle se lo puede ver de la siguiente manera (posicionándose cada vez en el directorio raíz de cada submódulo):...config/configurations/template$ git status # Not currently on any branch. # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: build_support/shared.maven.filters # modified: security-proxy/maven.filter # no changes added to commit (use "git add" and/or "git commit -a")...geonetwork$ git status # Not currently on any branch. # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: web/src/main/webapp/geoconfig.js # modified: web/src/main/webapp/web-inf/classes/meta-inf/services/javax.xml.transform.transformerfactory # modified: web/src/main/webapp/web-inf/config-gui.xml # modified: web/src/main/webapp/web-inf/config.xml # modified: web/src/main/webapp/web-inf/user-profiles.xml # modified: web/src/main/webapp/web-inf/web.xml # modified: web/src/main/webapp/index.html # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # web/src/main/webapp/web-inf/classes/log4j.properties... # web/src/main/webapp/xml/schemas/iso19139/schematron-rules-inspire.xsl no changes added to commit (use "git add" and/or "git commit -a")...geoserver/geoserver-submodule$ git status # On branch sibab # Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/gwc/target/... # src/wms/target/ nothing added to commit but untracked files present (use "git add" to track) En el caso de los archivos no seguidos por git ("untracked files") se ha elegido no mantener versionamiento de ellos ya que en su mayoría son archivos intermedios o temporales resultantes de las compilaciones, no contienen mayormente ninguna configuración, parámetro o definición que se necesite preservar. De todas maneras esto no es una regla y debe ponerse siempre el debido cuidado. En el caso de los archivos modificados ("changed but not updated"), en cambio, normalmente serán modificaciones realizadas por nosotros mismos, y debemos 12 of 65

13 indicarle a git si deseamos descartar el cambio realizado (git checkout --file) o deseamos preservarlo (git add, git commit -a). No existe un conjunto definido de archivos que se deban modificar en el codigo fuente de georchestra. Ello depende en gran medida del grado de customización que se busca, de la metodología de trabajo, y de otros factores. Casi siempre, de todas maneras, quedarán varias afinaciones por realizar después de la compilación. En el caso de customizaciones básicas-intermedias de georchestra, el principal submódulo sobre el cual trabajar es "config/configurations/template" Se ha procurado dar una visión panorámica muy ligera (incluyendo el flujo de trabajo, los comandos más usados, y el estado actual del código fuente bajo versionamiento) del trabajo que se ha relizado con la herramienta git para la obtención del georchestra. Está mucho más allá del alcance de esta documentación el brindar una capacitación detallada específica en la herramienta git. Abundante material está disponible en línea, y la ayuda en CLI linux (man git, git help command) es muy completa y avanzada. También el sitio de georchestra en GitHub [20] tiene documentación específica para la obtención en local de un repositorio propio del código georchestra bajo git. Posteriormente a una gestión adecuada del código fuente con git, viene la compilación de dicho código fuente. Se muestra a continuación, por secciones, el script de compilación en bash que se ha empleado en el trabajo: El siguiente código se posiciona en el directorio raíz del proyecto principal georchestra y recopila información de contexto: echo "CODIGO DE TRABAJO SIBAB" cd /home/georchestra/last_geor/georchestra pwd git status El siguiente código es el que de hecho efectúa realmente la compilación. Sus parámetros son: X significa modo debug explícito, es decir emite al stdout todos los mensajes Dmaven.test.skip=true significa omitir ciertos tests que no son imprescindibles e clean install significa no considerar residuos de compilaciones previas Ptemplate significa que se usará la carpeta template (mencionada anteriormente) como fuente de la configuración./mvn -X -Dmaven.test.skip=true -e clean install -Ptemplate echo "*******************************************************" echo "*******************************************************" 13 of 65

14 El siguiente código renombra y mueve los archivos war previamente disponibles (que se supone que funcionan bien) como un backup adicional: echo "...RENOMBRANDO ANTERIORES WARs" mv ~/geonetwork-private.war ~/geonetwork.war.prev mv ~/analytics-private.war ~/analytics.war.prev mv ~/mapfishapp-private.war ~/mapfishapp.war.prev mv ~/cas.war ~/cas.war.prev mv ~/ROOT.war ~/ROOT.war.prev mv ~/static.war ~/static.war.prev mv ~/geoserver-private.war ~/geoserver.war.prev mv ~/extractorapp-private.war ~/extractorapp.war.prev mv ~/downloadform-private.war ~/downloadform.war.prev sleep 2 El siguiente archivo renombra y mueve los archivos war generados en la compilación actual para su despliegue inmediato echo "...RENOMBRANDO Y MOVIENDO WARs ACTUALES" mv /home/georchestra/.m2/repository/org/geonetwork-opensource/geonetwork-main/2.6.4-snapshot/geonetwork-main s mv /home/georchestra/.m2/repository/org/georchestra/analytics/1.0/analytics-1.0-template.war ~/analytics-private.war #mv /home/georchestra/.m2/repository/org/georchestra/catalogapp/1.0/catalogapp-1.0-template.war ~/catalogapp-private mv /home/georchestra/.m2/repository/org/georchestra/mapfishapp/1.0/mapfishapp-1.0-template.war ~/mapfishapp-private. mv /home/georchestra/.m2/repository/org/georchestra/cas-server-webapp/1.0/cas-server-webapp-1.0-template.war ~/cas.w mv /home/georchestra/.m2/repository/org/georchestra/security-proxy/1.0/security-proxy-1.0-template.war ~/ROOT.war mv /home/georchestra/.m2/repository/org/georchestra/extractorapp/1.0/extractorapp-1.0-template.war ~/extractorapp-pr mv /home/georchestra/.m2/repository/org/georchestra/static/1.0/static-1.0-template.war ~/static.war mv /home/georchestra/.m2/repository/org/georchestra/downloadform/1.0/downloadform-1.0-template.war ~/downloadform-pr mv /home/georchestra/.m2/repository/org/georchestra/geoserver-webapp/1.0/geoserver-webapp-1.0-template.war ~/geoserv En el caso del presente trabajo, la ejecución y el monitoreo de cada compilación fueron ejecutados desde un servidor de integración continua jenkins. El siguiente gráfico generado por jenkins permite constatar que se han efectuad más de 146 compilaciones (147 exactamente, entre pruebas, actualizaciones remotas y actualizaciones locales [21] ). Las exitosas en azul, las fallidas en rojo: 14 of 65

15 Configuración del entorno y despliegue de las webapps Condiciones previas: georchestra precisa de las siguientes condiciones previamente a su despliegue: Un servidor LDAP instalado. En este trabajo se usó Openldap (específicamente: la linux appliance openldap de turnkey linux) [22] Un certificado SSL para la dirección pública del servidor. Para un despliegue estándar, la instalación apache2 debe contar con https y un certificado configurado Una base de datos para el almacenaje de datos geonetwork. En este trabajo se usó específicamente la linux appliance postgresql de turnkey linux [23] El LDAP debe estar configurado con usuarios y grupos/roles (y obviamente un usuario administrador). Cada usuario debe tener los campos mail, uid y cn El directorio debe observar también las siguientes reglas para los nombres de grupos/roles [24] : Los grupos/roles con el prefijo EL_ serán aplicados a los grupos Geonetwork Los grupos/roles con el prefijo SV_ son roles comunes a todos los módulos (en Geonetwork, los roles SV_ corresponden a los perfiles, en otras aplicaciones tienen otro significado) SV_ADMIN da permisos de administrador en todas las aplicaciones (excepto 15 of 65

16 geoserver) SV_EDITOR da derechos de escritura en una aplicación si esto aplica (actualmente, solo para Geonetwork y Mapfishapp) SV_REVIEWER da derechos de revisor (actualmente, solo para Geonetwork) SV_USER da solamente derechos de lectura sola en todas las aplicaciones pero el usuario, estando autenticado, puede beneficiar de otros permisos (dependiendo de la aplicación) GS_ADMIN es un rol especial para la administración de Geoserver. SV_ADMIN da un acceso completo a la configuración de geoserver, pero GS_ADMIN da acceso limitado a la configuración de los permisos de acceso a las capas. Un usuario con un rol GS_ADMIN debe tener también un rol GS_ADMIN_<FOO>. El <FOO> indica cual "agrupación de capas" el usuario/administrados tiene el derecho de administrar. La política de usuarios del portal, una vez pensada y definida, dispone de los anteriores instrumentos para su implementación efectiva. Es decir, para cada usuario y/o grupo/rol se definirán sus privilegios y restricciones mediante la aplicación de las anteriores reglas. Así, en el caso del usuario de ejemplo testadmin obsérvese cómo se aplican las anteriores reglas en la definición ldif: # SV_ADMIN, groups, georchestra.org dn: cn=sv_admin,ou=groups,dc=georchestra,dc=org objectclass: top objectclass: posixgroup gidnumber: 1 cn: SV_ADMIN memberuid: uid=testadmin,ou=users,dc=georchestra,dc=org memberuid: uid=gsadmin,ou=users,dc=georchestra,dc=org... # testadmin, users, georchestra.org dn: uid=testadmin,ou=users,dc=georchestra,dc=org sn: Person objectclass: organizationalperson objectclass: person objectclass: inetorgperson objectclass: top uid: testadmin description: USER description: ADMIN userpassword:: e1niqx1kreu1skevmkvpvtrgmffobut5expuazurn1e9 mail: psc@georchestra.org cn: testadmin El anterior código viene de: git clone --recursive Nótese que no se necesita hacer instalaciones ni configuraciones de inicio. Esto es debido a que (como ya indicado) se está trabajando no en un Debian normal, 16 of 65

17 sino en una appliance openldap. El repositorio clonado contiene los ldif de inicialización y de datos de ejemplo que se carga a continuación en el servidor LDAP: ldapadd -Dcn=admin,dc=georchestra,dc=org -f georchestra/georchestra-root.ldif -x -c -W ldapadd -Dcn=admin,dc=georchestra,dc=org -f georchestra/georchestra.ldif -x -c -W Se puede probar si todo ha salido exitosamente si el siguiente comando devuelve todos los registros recién cargados ldapsearch -x -bdc=georchestra,dc=org Se ha tenido éxito si el output es parecido a:... numresponses: 23 numentries: 22 En cuanto a postgresql (para el cual también se ha trabajado en una appliance postgresql), se crea a continuación la base de datos para GeoNetwork: su postgres createdb gn_georchestra createlang plpgsql gn_georchestra psql -f /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql gn_georchestra psql -f /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql gn_georchestra createuser www-data psql gn_georchestra > ALTER TABLE spatial_ref_sys OWNER TO "www-data"; > ALTER TABLE geometry_columns OWNER TO "www-data"; > ALTER TABLE geography_columns OWNER TO "www-data"; > ALTER USER "www-data" WITH PASSWORD 'www-data'; Ahora, en la appliance tomcat, se despliega los wars resultantes de la última compilación exitosa service tomcat6 stop cp cp ROOT.war /var/lib/tomcat6/webapps cp extractorapp-private.war /var/lib/tomcat6/webapps cp geoserver-private.war /var/lib/tomcat6/webapps cp static.war /var/lib/tomcat6/webapps cp cas.war /var/lib/tomcat6/webapps cp geonetwork-private.war /var/lib/tomcat6/webapps cp mapfishapp-private.war /var/lib/tomcat6/webapps service tomcat6 start Se muestra a continuación como debe quedar el archivo /etc/apache2/sites- 17 of 65

18 available/default: <VirtualHost *:80> ServerAdmin DocumentRoot /var/www/htdocs ServerName vm-georchestra ServerAlias vm-georchestra <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/htdocs> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/access.log combined Include /var/www/conf/georchestra.conf </VirtualHost> Se muestra a continuación como debe quedar el archivo /etc/apache2/sitesavailable/default-ssl: <IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/htdocs ServerName vm-georchestra ServerAlias vm-georchestra <Directory /> Options FollowSymLinks AllowOverride None </Directory> <Directory /var/www/htdocs> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all </Directory> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined SSLEngine on 18 of 65

19 SSLCertificateFile /etc/ssl/certs/cert-sibab.pem SSLCertificateKeyFile /etc/ssl/private/cert-sibab.key SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown Include /var/www/conf/georchestra.conf </VirtualHost> </IfModule> Ahora hay que generar el material SSL que hemos referenciado en las anteriores configuraciones: En un directorio temporal, crear una llave SSL: openssl genrsa -des3 -out myssl.key 1024 Indicar "georchestra" como la passphrase Después, crear una solicitud de firma de certificado openssl req -new -key myssl.key -out myssl.csr Responder con el anterior password, y responder las preguntas a continuación. La única realmente importante es: Common Name (eg, YOUR name) []: Para un servidor web, el CN del certificado debe ser el nombre del servidor que va a llamarse, por ejemplo si se desea llamar a " entonces el certificado CN debe ser "vm-georchestra". Ahora hay que desproteger la clave (acordarse de la passphrase). OpenSSL no permite la creación de llaves no protegidas. Desproteger la clave previa con: openssl rsa -in myssl.key -out myssl-unprotected.key Finalmente, generar el certificado y colocarlo en su lugar: openssl x509 -req -days 365 -in myssl.csr -signkey myssl.key -out myssl.crt cp myssl.crt /etc/ssl/certs/cert.pem cp myssl-unprotected.key /etc/ssl/private/cert.key 19 of 65

20 El servidor web Tomcat y SSL Crear un conector para tomcat6 en /var/lib/tomcat6/conf/server.xml: <Connector port="8443" protocol="http/1.1" SSLEnabled="true" maxthreads="150" scheme="https" secure="true" clientauth="false" sslprotocol="tls" keystorefile="/var/lib/tomcat6/ssl/vm-georchestra2.jks" keystorepass="secret2" /> Este conector puede definirse a cnotinuación del default 8080 (http regular) Generar un java keystore: cd /var/lib/tomcat6 mkdir ssl cd ssl keytool -genkey -alias mycert -keyalg RSA -keystore vm-georchestra.jks Aquí se debe ser cuidadoso: en las primera pregunta se debe responder con el Fully Qualified Domain Name (FQDN). Además, al password que sea solictado, se debe responder con el password establecido para el conector recién creado. A continuación, se debe incorporar este certificado al sistema global truststore. Exportando el certificado generado previamente: keytool -exportcert -alias mycert -file exported -keystore vm-georchestra2.jks El password (secret) será preguntado una vez más, y a continuación lo podemos importar en nuestro custom truststore: keytool -importcert -alias localhost -file exported -keystore cacerts2 Aquí debe suministrarse un password, el default password para el truststore provisto por el paquete debian original es "changeit" Ahora se puede modificar las variables de mabiente java para usar esta custom truststore en lugar de la del sistema en /etc/default/tomcat6, de modo que quede como sigue (se excluyen los comentarios): TOMCAT6_USER=tomcat6 TOMCAT6_GROUP=tomcat6 JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC" unset LC_ALL SSL_OPTS="-Djavax.net.ssl.trustStore=/var/lib/tomcat6/ssl/cacerts2 -Djavax.net.ssl.trustStorePassword=changeit" JAVA_OPTS="${JAVA_OPTS} ${SSL_OPTS}" GEOSERVER_DATA_DIR="/srv/geoserver_data" CATALINA_OPTS="-DGEOSERVER_DATA_DIR=${GEOSERVER_DATA_DIR}" 20 of 65