con software libre
Manual de Desarrollo
y Administración
Índice
1.Introducción... 3 2.Desarrollo – Alfresco... 4 2.1.1.Ficheros propios... 4 3.Administración – Alfresco... 7 3.1.Procedimiento de instalación...7 3.2.Procedimiento de migración...73.2.1.Alternativa 1: backup completo...7
3.2.2.Alternativa 2: backup de zona de datos...8
3.2.3.Otras alternativas... 8
3.2.4.Otros comentarios... 8
4.Desarrollo – Aplicaciones... 9
5.Administración – Aplicaciones...10
5.1.Módulos del sistema... 10
5.2.Estructura de directorios de la aplicación...10
5.3.Versiones de gemas Ruby... 12
5.4.Recomendaciones para el desarrollo...13
1. Introducción
El presente documento recoge el manual de Desarrollo y Administración de la intranet documental de Sartu.
Se desdobla en dos partes, atendiendo a las aplicaciones existentes de que consta la intranet:
• Alfresco, como gestor documental.
2. Desarrollo – Alfresco
2.1.1. Ficheros propios
Definición del modelo:
• Indicar nombre de fichero en
tomcat/shared/classes/alfresco/extension/custom-model-context.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'> <beans>
<!-- Registration of new models -->
<bean id="extension.dictionaryBootstrap" parent="dictionaryModelBootstrap" depends-on="dictionaryBootstrap"> <property name="models"> <list> <value>alfresco/extension/sartuModel.xml</value> </list> </property> </bean> </beans>
• Definición de tipos propios en
tomcat/shared/classes/alfresco/extension/sartuModel.xml
<?xml version="1.0" encoding="UTF-8"?> <!-- Sartu Model -->
<!-- Note: This model is pre-configured to load at startup of the Repository. So, all custom -->
<!-- types and aspects added here will automatically be registered --> <model name="sar:sartuModel" xmlns="http://www.alfresco.org/model/dictionary/1.0"> <!-- Optional meta-data about the model -->
<description>Modelo para Sartu</description> <author>Dani Gutiérrez</author>
<version>1.0</version> <imports>
<!-- Import Alfresco Dictionary Definitions -->
<import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d"/> <!-- Import Alfresco Content Domain Model Definitions -->
<import uri="http://www.alfresco.org/model/content/1.0" prefix="cm"/> </imports>
<!-- Introduction of new namespaces defined by this model -->
<!-- NOTE: The following namespace custom.model should be changed to reflect your own namespace -->
<namespaces>
<namespace uri="http://www.sartu.net/model/content/1.0" prefix="sar"/> </namespaces>
<types>
<title>Documento de Sartu</title> <parent>cm:content</parent> <associations> <association name="sar:relatedDocuments"> <title>Documentos relacionados</title> <source> <mandatory>false</mandatory> <many>true</many> </source> <target> <class>sar:doc</class> <mandatory>false</mandatory> <many>true</many> </target> </association> </associations> <mandatory-aspects> <aspect>cm:generalclassifiable</aspect> </mandatory-aspects> </type> <type name="sar:memoria"> <title>Memoria</title> <parent>sar:doc</parent> </type> </types> <aspects> <aspect name="sar:webable"> <title>Para la web</title> <properties> <property name="sar:published"> <type>d:date</type> </property> <property name="sar:isActive"> <type>d:boolean</type> <default>false</default> </property> </properties> </aspect> </aspects> </model>
Aspectos visibles y formularios de cliente Share:
• tomcat/webapps/share/WEB-INF/classes/alfresco/web-extensions/share-config-cu
stom.xml
<alfresco-config>
<!-- Document Library config section -->
<config evaluator="string-compare" condition="DocumentLibrary">
<aspects>
<!-- Aspects that a user can see --> <visible>
<aspect name="sar:webable" /> </visible>
<addable> </addable>
<!-- Aspects that a user can remove. Same as "visible" if left empty <removeable> </removeable> </aspects> <types> <type name="cm:content"> <subtype name="sar:doc" /> <subtype name="sar:memoria" /> </type> <type name="sar:doc"> <subtype name="sar:memoria" /> </type> </types> </config> </alfresco-config> Cadenas:
• Indicar nombre de fichero en
tomcat/shared/classes/alfresco/web-extension/custom-slingshot-application-conte xt.xml
• Escribir cadenas en
tomcat/webapps/share/WEB-INF/classes/alfresco/web-extension/messages/xxxM odel.properties
3. Administración – Alfresco
3.1. Procedimiento de instalación
• Descargar la versión de Alfresco de:
http://wiki.alfresco.com/wiki/Download_and_Install_Alfresco
• Cambiar los permisos a ejecutable y lanzar la instalación con el usuario adecuado
• Seleccionar instalación avanzada e indicar todos los componentes, con los valores
de puertos los que vienen por defecto:
◦ Componentes: Java, PostgreSQL, (Alfresco), SharePoint, Web Quick Start, OpenOffice
◦ Nombre del servidor
◦ Puertos de Tomcat: servidor 8080, cierre 8005, SSL 8443, AJP 8009
◦ Puerto FTP: 2121
◦ Puerto comandos remotos: 50500
◦ Puerto SharePoint: 7070
◦ Puerto servidor Openoffice: 8100
3.2. Procedimiento de migración
Se parte de dos servidores con una instalación de Alfresco en un mismo directorio en ambos. Sean:
• $ALF el directorio en el que se tiene la instalación de alfresco en ambos servidores. • $F el fichero $ALF/tomcat/shared/classes/alfresco-global.properties
• $D el valor de la entrada dir.root en $F • $DB el valor de la entrada db.name en $F • $U el valor de la entrada db.username en $F
3.2.1. Alternativa 1: backup completo
En el servidor de origen, detener alfresco y hacer una copia:
cd $ALF/..
tar czvf alfresco.tgz $ALF
En el servidor destino, detener alfresco, descomprimir la copia y arrancar alfresco mediante el script de dentro del directorio recién creado con la copia
3.2.2. Alternativa 2: backup de zona de datos
Es necesario borrar los índices de solr para que regenere las etiquetas.
En el servidor origen, detener alfresco y hacer una copia del directorio de datos: Hacer una copia del directorio indicado como dir.root en $F
cd $D/..
tar czvf repo.tgz $D En el servidor destino: 1. Detener alfresco
2. Hacer una copia de seguridad del directorio $ALF actual. 3. Descomprimir la copia
4. Borrar los ficheros de índice del motor de búsqueda Solr para que los regenere. Se encuentran en la entrada data.dir.store de los distintos ficheros de nombre
solrcore.properties bajo $ALF/solr/
ej. Alfresco-4.0.e/alf_data/solr/archive/SpacesStore 5. Arrancar alfresco.
Regeneración de índices de solr:
http://intranet.sartu.org:8080/solr/admin/cores?action=FIX
3.2.3. Otras alternativas
Es posible exportar zonas documentales a ficheros ACP mediante el cliente Alfresco (no el Share), pero no se guardan las etiquetas, con lo cual el método no es del todo válido.
3.2.4. Otros comentarios
• Importante tener los locales igual en ambos servidores (si es debian o variante, hacer
dpkg-reconfigure locales)
• Importante comprobar que el nombre del servidor, el puerto y el directorio de
instalación sea idéntico, porque hay referencias ej. en el fichero de configuración de postgresql o en los de solr.
4. Desarrollo – Aplicaciones
Ambas aplicaciones de gestión financiera y de partes tienen interface web, y para su desarrollo se ha elegido el framework web Ruby on Rails (abreviado como RoR o Rails), basado en Ruby, un lenguaje orientado a objetos, interpretado, y especialmente diseñado bajo el principio de “Least Surprise”.
Algunas características de RoR son:
• Ajax: Prototype, script.aculo.us, jQuery.
• Arquitectura MVC (Modelo-Vista-Controlador) y ORM (Mapeo relacional de Objetos):
mediante ActiveRecord y Action Pack.
• Soporte de internacionalización i10 y i18.
5. Administración – Aplicaciones
5.1. Módulos del sistema
Como software de servidor web, se ha seleccionado Apache con Phusion Passenger. Apache es el referente mundial de servidores web, al que se le añaden los módulos para Ruby y Rack, ambos empaquetados en el módulo libapache2-mod-passenger. Otras combinaciones posibles hubieran sido ej. Nginx con WEBrik (servidor por defecto de RoR) o Mongrel (superior al anterior). Las distintas posibilidades darán resultados diferentes de rendimiento o velocidad, y de consumo de recursos (memoria RAM).
Rack es un middleware para encapsular de forma muy sencilla peticiones y respuestas http desde ruby, unificando así los detalles de servidores y frameworks web diferentes.
Como base de datos se ha elegido MySQL, aunque de forma semejante al bloque de servidor web, es posible usar otros servidores web y otras BBDD (ej. SQLite o PostgreSQL).
5.2. Estructura de directorios de la aplicación
Denominando DIRBASE al directorio en el que se instala la aplicación, se tiene la siguiente estructura (se indican todos los directorios de primer nivel y los subdirectorios más significativos): DIRBASE |--- app |--- controllers |--- helpers |--- models |--- views |--- config |--- db |--- doc |--- files |--- lib |--- log |--- public |--- images |--- javascripts |--- stylesheets |--- script |--- test
|--- tmp |--- vendor
Salvo en lo referente a la carpeta files, esta estructura de directorios es la estándar en todo proyecto Ruby on Rails.
La información contenida en cada directorio es la siguiente:
• apps: código de la aplicación, con subdirectorio para MVC y helpers (ficheros
auxiliares para dejar código en las vistas, que no se puede dejar en en el modelo o el controlador, y que se separa de la vista para no dificultar la lectura del lenguaje markup en ésta).
• cfg: configuración de la conexión a la base de datos, al servidor SMTP, localizaciones
para internacionalización.
• db: esquema de la base de datos, comandos de creación de la misma, y datos de
carga inicial.
• lib: ficheros de tareas para Rake (en formato .rake). • log: logs o trazas.
• public: ficheros web: html, imágenes (gif, png, jpg), css, javascript (.js). • script: utilidades varias.
• tmp: información temporal como caché, PIDs, sesiones y sockets. También se
almacena aquí el backup de base de datos.
• vendor: gemas y plugins de terceros adicionales.
Por otra parte, files es el directorio para dejar archivos varios, ej. backups de ficheros e informes.
5.3. Versiones de gemas Ruby
• abstract (1.0.0) • actionmailer (3.0.12) • actionpack (3.0.12) • activemodel (3.0.12) • activerecord (3.0.12) • activeresource (3.0.12) • activesupport (3.0.12) • arel (2.0.10) • bluecloth (2.2.0) • builder (2.1.2) • bundler (1.2.0) • dryml (1.3.0) • erubis (2.6.6) • hobo (1.3.0) • hobo_fields (1.3.0) • hobo_support (1.3.0) • i18n (0.5.0) • json (1.7.5) • mail (2.2.19)• mime-types (1.19) • polyglot (0.3.3) • rack (1.2.5) • rack-mount (0.6.14) • rack-test (0.5.7) • rails (3.0.12) • railties (3.0.12) • rake (0.9.2.2) • rdoc (3.12) • ruby-ole (1.2.11.4) • rubygems-bundler (1.1.0) • rvm (1.11.3.5) • spreadsheet (0.7.3) • sqlite3 (1.3.6) • thor (0.14.6) • to_xls (1.5.1) • treetop (1.4.10) • tzinfo (0.3.33) • will_paginate (3.0.3)
• Emplear entornos de desarrollo, de pruebas y de producción. Para ello, la
configuración a realizar es la correspondiente a ambos en el fichero config/database.yml, haciéndose la carga de datos respectiva mediante:
• # export RAILS_ENV=development
• # rake db:seed
• Emplear máquinas virtuales para demostraciones. Ej. VirtualBox.