health-es
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-es] Sugerencias sobre el instalador


From: Luis González
Subject: Re: [Health-es] Sugerencias sobre el instalador
Date: Tue, 22 Jul 2014 09:23:38 -0430

Hola:

Perfecto! Mientras más problemas se puedan evitar (o al menos
advertir) durante la instalación, mejor.

"Cuando haces la instalación la primera vez, creas la compañía y la
institución de salud?":
Pues no, de hecho salté todos los asistentes para probar el --update,
quizás el problema se de por eso. Sin embargo, supongo que a pesar de
eso, no debería producirse ese error.

El 22/7/14, Luis Falcon <address@hidden> escribió:
> Hola Luis
> On Mon, 21 Jul 2014 14:36:10 -0430
> Luis González <address@hidden> wrote:
>
>> Hola Luis.
>>
>> Me parece que tienes razón, la verdad no había imaginado una situación
>> en donde estuvieran ejecutándose más de una instancia del servidor (al
>> menos no con el mismo usuario).
>>
> Perfecto ! Ya pongo el task para verificar que el
> archivo /etc/trytond.conf no exista cuando se utiliza el instalador
> estándar.
>
>> Creo que la solución que propones es la mejor, la única desventaja
>> sería que no se podría instalar conservando ese archivo, aunque ya esa
>> sería una situación inusual.
>>
>> La segunda mejor solución(a mi criterio) sería fijar la variable sólo
>> si el archivo existe.
>>
>> En otro orden de ideas, creo haber encontrado un bug. Lo he podido
>> replicar en instalaciones limpias de GNU Health.
>>
>> Lo único que hice fue:
>> 1. Instalar GNU Health y crear la base de datos.
>> 2. Instalar el módulo Health y sus dependencias
>> 3. ejecutar:
>> ./trytond --update health -d gnuhealth2
>>
>> Y durante el proceso me arroja este error:
>> ------------------------------------------------------------
>> Traceback (most recent call last):
>>   File "./trytond", line 113, in <module>
>>     trytond.server.TrytonServer(options).run()
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/server.py",
>> line 123, in run Pool(db_name).init(update=update, lang=lang)
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/pool.py",
>> line 151, in init lang=lang)
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> line 428, in load_modules _load_modules()
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> line 396, in _load_modules load_module_graph(graph, pool, lang)
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/__init__.py",
>> line 237, in load_module_graph cls.__register__(module)
>>   File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/modules/health/health.py",
>> line 678, in __register__ CONSTRAINT
>> gnuhealth_hospital_building_institution_fkey;") File
>> "/home/prueba/gnuhealth/tryton/server/trytond-3.2.1/trytond/backend/postgresql/database.py",
>> line 311, in execute return self.cursor.execute(sql)
>> psycopg2.ProgrammingError: constraint
>> "gnuhealth_hospital_building_institution_fkey" of relation
>> "gnuhealth_hospital_building" does not exist
>> ------------------------------------------------------------
>>
>> No tengo mucha noción sobre el funcionamiento de las tablas de GNU
>> Health, pero según tengo entendido, no existen claves foráneas en
>> ellas. Imagino que ese "fkey" significa "foreign key".
> Sí hay (y muchas :) ). Campos relacionales como el M2O usan claves
> foráneas.
>>
>> Por cierto, este error lo encontré porque estoy haciendo
>> modificaciones frecuentes a los módulos, y cada vez que hago un -u
>> all, me aparece. Imagino que cuando sucede esto, se interrumpe el
>> proceso.
>>
> Es raro, porque este bloque sólo se debería ejecutar una vez en el
> primer upgrade de versiones de GNU Health antiguas, donde el modelo de
> institución está vacío.
>
> Cuando haces la instalación la primera vez, creas la compañía y la
> institución de salud?
>
> Gracias !
>> El 21/7/14, Luis Falcon <address@hidden> escribió:
>> > Hola Luis
>> >
>> > On Mon, 21 Jul 2014 10:03:34 -0430
>> > Luis González <address@hidden> wrote:
>> >
>> >> Si el archivo "/etc/trytond.conf" existe, el servidor de GNU Health
>> >> fallará cuando se inicie. El servidor intentará utilizarlo como su
>> >> archivo de configuración, lo que provocará un error por no tener
>> >> permisos de lectura (como le sucedió a Cecilia), o en el mejor de
>> >> los casos, se iniciará con una configuración incorrecta. Esto se
>> >> puede prevenir colocando la siguiente línea en el archivo
>> >> gnuhealthrc: export
>> >> TRYTOND_CONFIG="${GNUHEALTH_DIR}/tryton/server/${TRYTOND}/etc/trytond.conf"
>> >>
>> >> De manera de indicarle explícitamente que, para ese usuario,
>> >> utilice ese archivo así existan otros.
>> >>
>> >
>> > Gracias por la sugerencia !
>> >
>> > Si el archivo /etc/trytond.conf existe es porque se ha dejado de una
>> > instalación de Tryton que no debería estar.
>> >
>> > La mejor solución es seguir la instalación, en un entorno limpio.
>> > De lo contrario, aparecerán otros problemas (precedencia de
>> > librerías, etc..). Entonces, al final pasamos más tiempo
>> > "parcheando" un sistema que no está limpio, y nunca estaremos
>> > seguros.
>> >
>> > Una instalación standard (sistema limpio, sin /etc/trytond.conf)
>> > toma el mismo path que la variable de entorno TRYTOND_CONFIG
>> > tomaría. El problema está en que esta variable es de entorno. No
>> > aplicaría bien en ambientes de desarrollo, con varias instancias
>> > por el mismo usuario corriendo en distintos puertos, habría que
>> > sobrescribir el valor pasándole como argumento la opción "--config"
>> > a cada daemon de tryton que queramos ejecutar.
>> >
>> > Creo que esta variable de entorno puede generar más problema que
>> > solución. Pero me parece muy válida tu sugerencia y de hecho,
>> > debemos analizarlo más detalladamente.
>> >
>> > Lo que me parece que deberíamos hacer, independientemente de la
>> > decisión final sobre la variable, es verificar en la instalación
>> > que el archivo "/etc/trytond.conf" no exista. Si existe, la
>> > instalación debe parar y advertir de una posible instancia previa
>> > de Tryton que genera conflictos.
>> >
>> >
>> > Gracias !
>> >
>> >> El 17/7/14, Luis González <address@hidden> escribió:
>> >> > Al intentar acceder al grupo "Administración" (Usuarios ->
>> >> > Grupos -> Administración) me aparecía un error. Cada vez que lo
>> >> > intentaba, me sucedía lo mismo. Sin embargo, reinicié el cliente
>> >> > y ya no puedo reproducirlo.
>> >> >
>> >> > Por fortuna, copié el traceback, aquí va:
>> >> > Traceback (most recent call last):
>> >> >   File "/trytond/protocols/jsonrpc.py", line 125, in
>> >> > _marshaled_dispatch response['result'] = dispatch_method(method,
>> >> > params) File "/trytond/protocols/jsonrpc.py", line 158, in
>> >> > _dispatch res = dispatch(*args)
>> >> >   File "/trytond/protocols/dispatcher.py", line 158, in dispatch
>> >> >     result = rpc.result(meth(*c_args, **c_kwargs))
>> >> >   File "/trytond/model/modelsql.py", line 638, in read
>> >> >     getter_result = field.get(ids, cls, fname, values=result)
>> >> >   File "/trytond/res/group.py", line 31, in get
>> >> >     ids.remove(id_)
>> >> > AttributeError: 'tuple' object has no attribute 'remove'
>> >> >
>> >> > No se si sea importante, pero igual lo informo por si a caso.
>> >> >
>> >> > Si encuentro la forma de reproducirlo, avisaré
>> >> >
>> >> > El 16/7/14, Luis González <address@hidden> escribió:
>> >> >> Excelente!! Muchas gracias... :)
>> >> >>
>> >> >> El 16/7/14, Luis Falcon <address@hidden> escribió:
>> >> >>> Hola !
>> >> >>> On Wed, 16 Jul 2014 16:50:17 +0100
>> >> >>> Luis Falcon <address@hidden> wrote:
>> >> >>>
>> >> >>>> Buenas tardes Luis
>> >> >>>> On Tue, 15 Jul 2014 21:34:04 -0430
>> >> >>>> Luis González <address@hidden> wrote:
>> >> >>>>
>> >> >>>> > Buenas tardes nuevamente.
>> >> >>>> >
>> >> >>>> > Tengo 2 recomendaciones más para el instalador.
>> >> >>>> >
>> >> >>>> > 1. Sí el instalador no se ejecuta exactamente desde su
>> >> >>>> > carpeta contenedora, la instalación falla cuando intenta
>> >> >>>> > copiar los módulos. Esto se puede prevenir fácilmente
>> >> >>>> > cambiando la línea: INSTDIR="$PWD"
>> >> >>>> >
>> >> >>>> Es que se debe ejecutar desde su carpeta.
>> >> >>>> > por:
>> >> >>>> > INSTDIR=`cd "$(dirname "$0")" && pwd`
>> >> >>>> >
>> >> >>>> > Esto haría el instalador un poco más robusto
>> >> >>>> >
>> >> >>>> > 2. En el archivo "gnuhealthrc", se asume que GNU Health está
>> >> >>>> > instalado en $HOME/gnuhealth. Si bien esta es la
>> >> >>>> > configuración por defecto, esto no siempre será así (como
>> >> >>>> > en mi instalación). Además, no siempre se hace referencia al
>> >> >>>> > directorio de la misma forma (a veces $HOME/gnuhealth, a
>> >> >>>> > veces ${HOME}... ), lo que dificulta hacer algo como un
>> >> >>>> > "reemplazar todos". Lo ideal sería que estuviera en una
>> >> >>>> > variable al estilo de: INSTDIR="$HOME/gnuhealth"
>> >> >>>>
>> >> >>>> Me gusta la idea de INSTDIR. Igualmente, por defecto debería
>> >> >>>> siempre apuntar a $HOME/gnuhealth .
>> >> >>>
>> >> >>> Hecho en
>> >> >>> http://hg.savannah.gnu.org/hgweb/health/rev/096774c2abf3
>> >> >>>
>> >> >>> Uso GNUHEALTH_DIR para no confundirla con ${INSTDIR} del
>> >> >>> instalador
>> >> >>>
>> >> >>> Gracias !
>> >> >>>
>> >> >>>>
>> >> >>>> Lo aplicaremos en el default branch .
>> >> >>>>
>> >> >>>> Gracias !
>> >> >>>>
>> >> >>>> >
>> >> >>>> > De manera que se pueda cambiar fácilmente; o por lo menos
>> >> >>>> > que siempre se hiciera referencia al directorio de la misma
>> >> >>>> > forma, utilizando la misma nomenclatura.
>> >> >>>> >
>> >> >>>> > El 14/7/14, Luis Falcon <address@hidden> escribió:
>> >> >>>> > > Hola Luis
>> >> >>>> > > On Mon, 14 Jul 2014 17:56:40 -0430
>> >> >>>> > > Luis González <address@hidden> wrote:
>> >> >>>> > >
>> >> >>>> > >> Buenas tardes nuevamente.
>> >> >>>> > >>
>> >> >>>> > >> Les escribo porque tengo algunas sugerencias  para el
>> >> >>>> > >> instalador de GNU Health, que podrían facilitar su
>> >> >>>> > >> instalación en algunos sistemas. Si este no es el lugar
>> >> >>>> > >> correcto para este tipo de propuestas, por favor
>> >> >>>> > >> háganmelo saber
>> >> >>>> > >>
>> >> >>>> > >> He logrado instalar GNU Health 2.6 bajo la versión
>> >> >>>> > >> estable de CentOS (Release v6.5 Final). En esta
>> >> >>>> > >> distribución, la versión de Python incluída es la 2.6.6.
>> >> >>>> > >>
>> >> >>>> > >>  Debido a que GNU Health necesita una versión >= 2.7, y
>> >> >>>> > >> que modificar la versión que viene con el sistema produce
>> >> >>>> > >> incompatibilidades, es necesario realizar una instalación
>> >> >>>> > >> paralela de Python 2.7. Esto instala el binario
>> >> >>>> > >> "python2.7" y (una vez instalado pip) el binario "pip2.7.
>> >> >>>> > >>
>> >> >>>> > >> Mi sugerencia es que el instalador pueda detectar el
>> >> >>>> > >> nombre de este ejecutable, similar a como se hace con el
>> >> >>>> > >> comando pip (que puede funcionar con "pip", "pip2" y
>> >> >>>> > >> "python-pip"). Por ejemplo, se podría colocar algo como
>> >> >>>> > >> esto:
>> >> >>>> > >>
>> >> >>>> > > Muchas gracias por tus sugerencias.
>> >> >>>> > > Hay un grupo que  está trabajando sobre la documentación
>> >> >>>> > > de la instalación de GNU Health sobre CentOS,
>> >> >>>> > > que se incluirá en el Wikibook (en Inglés incialmente) en
>> >> >>>> > > los próximos días.
>> >> >>>> > >
>> >> >>>> > > La versión actual del instalador tiene un "detector" de
>> >> >>>> > > algunos sistemas operativos (FreeBSD, GNU/Linux) así como
>> >> >>>> > > versiones de distros de GNU/Linux.
>> >> >>>> > >
>> >> >>>> > > Con esto como base, ya podemos ir "parametrizando" las
>> >> >>>> > > instalaciones dependiendo del sabor del OS que encuentre.
>> >> >>>> > > Sin duda, tus recomendaciones son más que bienvenidas y lo
>> >> >>>> > > estaremos incluyendo tus consejos.
>> >> >>>> > >
>> >> >>>> > > Saludos !
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> > >> ------------------------------------------------------------
>> >> >>>> > >> local PYTHON_NAMES="python2.7 python2 python"
>> >> >>>> > >> PYTHON_NAME=""
>> >> >>>> > >> for NAME in ${PYTHON_NAMES}; do
>> >> >>>> > >>     if [[ `which ${NAME} 2>/dev/null` ]]; then
>> >> >>>> > >>         PYTHON_NAME=${NAME}
>> >> >>>> > >>         break
>> >> >>>> > >>     fi
>> >> >>>> > >> done
>> >> >>>> > >> ------------------------------------------------------------
>> >> >>>> > >>
>> >> >>>> > >> O en su defecto utilizar una variable que almacene el
>> >> >>>> > >> ejecutable de python, por ejemplo:
>> >> >>>> > >> $PITHON_CMD
>> >> >>>> > >>
>> >> >>>> > >> De manera que sea más fácil cambiar su valor en todo el
>> >> >>>> > >> script.
>> >> >>>> > >>
>> >> >>>> > >> Por otro lado, en los posibles nombres para el
>> >> >>>> > >> ejecutable de "pip" se podría añadir "pip2.7, cambiando
>> >> >>>> > >> la línea: local PIP_NAMES="pip pip2 pip-python"
>> >> >>>> > >>
>> >> >>>> > >> Por esta otra:
>> >> >>>> > >> local PIP_NAMES="pip2.7 pip pip2 pip-python"
>> >> >>>> > >>
>> >> >>>> > >> Por último, cuando el instalador encuentra que ya existe
>> >> >>>> > >> el directorio "/tmp/gnuhealth_installer" no debería
>> >> >>>> > >> fallar la instalación, debería borrar el directorio (al
>> >> >>>> > >> fin y al cabo es un directorio temporal) o crear uno
>> >> >>>> > >> distinto.
>> >> >>>> > >>
>> >> >>>> > >> Cualquier duda con esta información, no duden en
>> >> >>>> > >> preguntar...
>> >> >>>> > >>
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> > > --
>> >> >>>> > > Dr. Luis Falcon
>> >> >>>> > > GNU Health
>> >> >>>> > > Freedom and Equity in Healthcare
>> >> >>>> > > http://health.gnu.org
>> >> >>>> > >
>> >> >>>> > >
>> >> >>>> >
>> >> >>>> >
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Salu2
>> >> >> Luis F. González V.
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Salu2
>> >> > Luis F. González V.
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>


-- 
Salu2
Luis F. González V.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]