dhis2-devs team mailing list archive
-
dhis2-devs team
-
Mailing list archive
-
Message #19628
[Branch ~dhis2-documenters/dhis2/dhis2-docbook-docs] Rev 600: Minor changes
------------------------------------------------------------
revno: 600
committer: Inés Bebea <ines.bebea@xxxxxxxxxx>
branch nick: dhis2-docbook-docs
timestamp: Mon 2012-10-22 19:08:59 +0200
message:
Minor changes
added:
src/docbkx/es/resources/images/admon/caution.png
src/docbkx/es/resources/images/admon/image_license.txt
src/docbkx/es/resources/images/admon/important.png
src/docbkx/es/resources/images/admon/tip.png
src/docbkx/es/resources/images/admon/warning.png
modified:
src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml
src/docbkx/es/dhis2_implementation_guide_installation.xml
--
lp:~dhis2-documenters/dhis2/dhis2-docbook-docs
https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs
Your team DHIS 2 developers is subscribed to branch lp:~dhis2-documenters/dhis2/dhis2-docbook-docs.
To unsubscribe from this branch go to https://code.launchpad.net/~dhis2-documenters/dhis2/dhis2-docbook-docs/+edit-subscription
=== modified file 'src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml'
--- src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-09-27 08:55:25 +0000
+++ src/docbkx/es/dhis2_implementation_guide_deployment_strategies.xml 2012-10-22 17:08:59 +0000
@@ -2,22 +2,22 @@
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN" "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd"; []>
<chapter>
<title>Estrategias de despliegue</title>
- <para>DHIS 2 is a network enabled application and can be accessed over the Internet, a local intranet and as a locally installed system. The deployment alternatives for DHIS 2 are in this chapter defined as i) offline deployment ii) online deployment and iii) hybrid deployment. The meaning and differences will be discussed in the following sections.</para>
+ <para>DHIS 2 es una aplicación para trabajar en red y puede accederse desde Internet, desde una intranet local y como sistema instalado localmente. Las alternativas de despliegue de DHIS 2 se definen en este capítulo como: offline, online o híbridas. En las secciones siguientes discutiremos su significado y diferencias.</para>
<section>
<title>Despliegue Desconectado (Offline)</title>
- <para>An offline deployment implies that multiple standalone offline instances are installed for end users, typically at the district level. The system is maintained primarily by the end users/district health officers who enters data and generate reports from the system running on their local server. The system will also typically be maintained by a national super-user team who pay regular visits to the district deployments. Data is moved upwards in the hierarchy by the end users producing data exchange files which are sent electronically by email or physically by mail or personal travel. (Note that the brief Internet connectivity required for sending emails does not qualify for being defined as online). This style of deployment has the obvious benefit that it works when appropriate Internet connectivity is not available. On the other side there are significant challenges with this style which are described in the following section.</para>
+ <para>Un despligue offline implica que instalamos muchas instancias autónomas offline para los usuarios finales, generalmente a nivel de distrito. El sistema lo mantienen principalmente los usuarios, trabajadores de salud en distrito, que introducen los datos y generan reportes utilizando su servidor local. Típicamente hay también un equipo de superusuarios a nivel nacional que mantiene el sistema y realizar visitas regularmente a los despliegues en distritos. Los usuarios envían los datos hacia arriba en la jerarquía produciendo ficheros de intercambio de datos que se envían electrónicamente por email o físicamente por correo convencional o viajes del personal. Notemos que aunque haya una conexión reducida a Intenret para enviar emails, puede no ser suficiente para que el sistema sea online. Esta forma de despliegue tiene el beneficio claro de que funciona cuando no disponemos de una conectividad de Internet apropiada. Por otro lado hay algunos retos significativos en esta forma de desplique, que se describen a continuación.</para>
<itemizedlist>
<listitem>
- <para>Hardware: Running stand-alone systems requires advanced hardware in terms of servers and reliable power supply to be installed, usually at district level, all over the country. This requires appropriate funding for procurement and plan for long-term maintenance.</para>
- </listitem>
- <listitem>
- <para>Software platform: Local installs implies a significant need for maintenance. From experience, the biggest challenge is viruses and other malware which tend to infect local installations in the long-run. The main reason is that end users utilize memory sticks for transporting data exchange files and documents between private computers, other workstations and the system running the application. Keeping anti-virus software and operating system patches up to date in an offline environment are challenging and bad practises in terms of security are often adopted by end users. The preferred way to overcome this issue is to run a dedicated server for the application where no memory sticks are allowed and use an Linux based operating system which is not as prone for virus infections as MS Windows.</para>
- </listitem>
- <listitem>
- <para>Software application: Being able to distribute new functionality and bug-fixes to the health information software to users are essential for maintenance and improvement of the system. Relying on the end users to perform software upgrades requires extensive training and a high level of competence on their side as upgrading software applications might a technically challenging task. Relying on a national super-user team to maintain the software implies a lot of travelling.</para>
- </listitem>
- <listitem>
- <para>Database maintenance: A prerequisite for an efficient system is that all users enter data with a standardized meta-data set (data elements, forms etc). As with the previous point about software upgrades, distribution of changes to the meta-data set to numerous offline installations requires end user competence if the updates are sent electronically or a well-organized super-user team. Failure to keep the meta-data set synchronized will lead to loss of ability to move data from the districts and/or an inconsistent national database since the data entered for instance at the district level will not be compatible with the data at the national level.</para>
+ <para>Hardware: Tener en funcionamiento sistemas autónomos requiere un hardware más avanzado en términos de instalar servidores y suministro eléctrico fiable, generalmente a nivel de distrito, en todo el país. Esto requiere una financiación apropiada para la adquisición de equipos y la planificación de mantenimiento a largo plazo.</para>
+ </listitem>
+ <listitem>
+ <para>Plataforma software: Las instalaciones locales implican una necesidad importante de mantenimiento. De la experiencia de HISP, el mayor reto son los viruses y otros malwares que tienden a infectar las instalaciones locales a largo plazo. La razón principal para esto es que los usuarios utilizan dispositivos de memoria externa USB para transportar los ficheros de intercambio de datos y documentos entre computadoras privadas, otras computadoras de red y el sistema en el que funciona la aplicación DHIS. Mantener sofware antivirus y parches de sistema operativo actualizados en un entorno offline es dificultoso y una mala práctica en términos de seguridad muy común entre los usuarios. Tal vez la mejor manera de evitar esto es lanzar un servidor dedicado para la aplicación donde no se utilicen memorias externas y se utilice un sistema operativo basado en Linux, que no sea susceptible de infecciones de virus como lo es MS Windows.</para>
+ </listitem>
+ <listitem>
+ <para>Aplicación software: Being able to distribute new functionality and bug-fixes to the health information software to users are essential for maintenance and improvement of the system. Relying on the end users to perform software upgrades requires extensive training and a high level of competence on their side as upgrading software applications might a technically challenging task. Relying on a national super-user team to maintain the software implies a lot of travelling.</para>
+ </listitem>
+ <listitem>
+ <para>Mantenimiento de la base de datos: A prerequisite for an efficient system is that all users enter data with a standardized meta-data set (data elements, forms etc). As with the previous point about software upgrades, distribution of changes to the meta-data set to numerous offline installations requires end user competence if the updates are sent electronically or a well-organized super-user team. Failure to keep the meta-data set synchronized will lead to loss of ability to move data from the districts and/or an inconsistent national database since the data entered for instance at the district level will not be compatible with the data at the national level.</para>
</listitem>
</itemizedlist>
</section>
=== modified file 'src/docbkx/es/dhis2_implementation_guide_installation.xml'
--- src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-10-18 09:47:39 +0000
+++ src/docbkx/es/dhis2_implementation_guide_installation.xml 2012-10-22 17:08:59 +0000
@@ -105,9 +105,9 @@
<para>Ahora podemos iniciar y detener nginx con los comandos siguientes:</para>
<para><screen>sudo /usr/local/nginx/sbin/nginx
sudo /usr/local/nginx/sbin/nginx -s stop</screen></para>
- <para>Ahora que hemos instalado nginx continuaremos configurando el proxy regular de peticiones a nuestra instancia Tomcat, que asumimos que se ejecuta en <emphasis role="italic">http://localhost:8080</emphasis>. Para configurar nginx podemos abrir el fichero de configuración invocando:</para>
+ <para>Ahora que hemos instalado nginx continuaremos configurando el proxy regular de peticiones a nuestra instancia de Tomcat, que asumimos que se ejecuta en <emphasis role="italic">http://localhost:8080</emphasis>. Para configurar nginx podemos abrir el fichero de configuración invocando:</para>
<para><code>sudo nano /usr/local/nginx/conf/nginx.conf</code></para>
- <para>La configuración de nginx se monta en torno a una jerarquía de bloques que incluye http, servidor y ubicación, donde cada bloque hereda los parámetros configurados en los bloques padre. El código siguiente configura nginx para pasar por proxy (redireccionar) las peticiones del puerto 80 (que es el puerto que nginx escucha por defecto) a nuestra instancia Tomcat. Con esto también conseguimos que nginx sirva peticiones de contenido estático como son javascript, hojas de estilo e imágenes, e instruya a los clientes para guardarlas en caché durante 4 días, de modo que se reduce la carga de Tomcat y se mejora el rendimiento en general. Por eso, añadiremos la configuración siguiente en el fichero nginx.conf:</para>
+ <para>La configuración de nginx se monta en torno a una jerarquía de bloques que incluye http, servidor y ubicación, donde cada bloque hereda los parámetros configurados en los bloques padre. El código siguiente configura nginx para pasar por proxy (redireccionar) las peticiones del puerto 80 (que es el puerto que nginx escucha por defecto) a nuestra instancia de Tomcat. Con esto también conseguimos que nginx sirva peticiones de contenido estático como son javascript, hojas de estilo e imágenes, e instruya a los clientes para guardarlas en caché durante 4 días, de modo que se reduce la carga de Tomcat y se mejora el rendimiento en general. Por eso, añadiremos la configuración siguiente en el fichero nginx.conf:</para>
<para><screen><