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 Falcon
Subject: Re: [Health-es] Sugerencias sobre el instalador
Date: Tue, 22 Jul 2014 15:05:45 +0100

Buenas tardes Luis
On Tue, 22 Jul 2014 09:23:38 -0430
Luis González <address@hidden> wrote:

> 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.
> 
Por eso :) Es importante terminar el asistente de la compañía y crear
la institución. Después vas a poder hacer el update sin problema.

A veces está bien no ocultar lo anómalo. Por ejemplo, en este caso, uno
podría evitar el traceback, pero realmente el problema está en que la
instalación inicial no se ha terminado, y estás intentando hacer
un upgrade sobre la misma.

Gracias nuevamente .

Saludos !

> 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.
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
> 
> 




reply via email to

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