Se caen los sitios

kommodin · Avril 23, 2007, 2:08

Hola,

He tenido un fin de semana preocupante porque varios de mis sitios se cayeron sin explicación alguna, el navegador muestra un mensaje de error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
como se ve en http://www.pazfuerzayalegria.net/

Al parecer es un problema de configuración del servidor, por tanto no parece tener nada que ver con SPIP. No les escribiría si no fuera porque me pasó exactamente lo mismo en dos servidores, de diferentes proveedores y además (que es lo que llama la atención) si no notara que otras aplicaciones LAMP siguen funcionando perfectamente (por ejemplo: http://galeria.pazfuerzayalegria.net/main.php

No he empezado a recuperar los sitios de este servidor (son tres) porque tengo urgencia de entregar el otro al cliente. Para poder recuperar en el otro servidor, lo primero que probé fue borrar la caché manualmente (en la carpeta /tmp/cache es un SPIP 1.9.2) no funcionó, también borre los datos de /tmp/sessions y /tmp/visites nada.

Para descartar que no fuera un problema de configuración del PHP instalé un Drupal usando Fantastico desde el panel de control, todo perfecto.

Después decidí borrar el archivo /config/inc-connect.php Me alegré mucho cuando en primera plana me mostró un letrero de sitio en curso de modificación, pude reinstalarlo y ver el espacio privado (la base de datos estaba intacta), pero después cuando intenté ver el lado público no funcionó, volvió a mostrar el error y perdí el acceso al área privada. Tuve que borrarlo por completo e instalarlo de nuevo, ahora está funcionando pero gaste mucho tiempo en esa operación.

El que recuperé es un sitio nuevo, así que a pesar de todo fue relativamente sencillo. Me preocupan los que me faltan que son sitios con muchos artículos y esqueletos complejos. Datos curiosos: en ese servidor tengo instalados cuatro SPIP, se dañaron 3, el que salvó también tiene esqueletos complejos, pero dos de los que cayeron tienen apenas unos pequeños retoques al esqueleto dist. En esos tengo las dos versiones de SPIP 1.9 (no tengo a mano el dato exacto pero recuerdo que unos son más actualizados que otros). También se cayó un eGroupWare y dos instalaciones de PHPlist, sobrevivieron un Moodle, dos instalaciones de Gallery

¿Creen que los esqueletos tendrán algo que ver con el problema?
¿Alguien sabe como salir de estar sin tener que volver a montar todo el sistema?

Muchas gracias,

Germán

--

Germán Bustos
german_bustos@gmx.net
http://www.atarraya.org/german

Fernando_Toledo · Avril 23, 2007, 3:36

El Lunes, 23 de Abril de 2007 11:08, German Bustos escribió:

Hola,

He tenido un fin de semana preocupante porque varios de mis sitios se
cayeron sin explicación alguna, el navegador muestra un mensaje de error
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
como se ve en http://www.pazfuerzayalegria.net/

un acontecimiento impotante fue que Debian cambio su version estable
ahora en la nueva version hay php5 y mysql5 y muchas cosas nuevas, quizas los
admins de esos sitios hicieron update sin revisar bien si todo funcionaba
de todas formas, deberian ser ajustes minimos

--
Dock Sud BBS

telnet://bbs.docksud.com.ar

Pablo_Iranzo_G_mez · Avril 23, 2007, 4:05

Llevo mucho con php5 y mysql5 y no he tenido ningún problema

Saludos
Pablo

--
Pablo Iranzo Gómez
(http://Alufis35.uv.es/~iranzo/)
(PGPKey Available on http://www.uv.es/~iranzop/PGPKey.pgp)
--
Postulado de Boling sobre la Ley de Murphy:

Si se encuentra bien, no se preocupe. Se le pasará

El 23/04/07, Fernando Toledo <ftoledo@docksud.com.ar> escribió:

El Lunes, 23 de Abril de 2007 11:08, German Bustos escribió:
> Hola,
>
> He tenido un fin de semana preocupante porque varios de mis sitios se
> cayeron sin explicación alguna, el navegador muestra un mensaje de error
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
> como se ve en http://www.pazfuerzayalegria.net/
>
un acontecimiento impotante fue que Debian cambio su version estable
ahora en la nueva version hay php5 y mysql5 y muchas cosas nuevas, quizas los
admins de esos sitios hicieron update sin revisar bien si todo funcionaba
de todas formas, deberian ser ajustes minimos

--
Dock Sud BBS
http://www.docksud.com.ar
telnet://bbs.docksud.com.ar

_______________________________________________
Spip-es@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-es

kommodin · Avril 23, 2007, 4:17

Gracias por sus respuestas,

Estoy intentando que el proveedor me de más información, por ahora encontré que están actualizando PHP y usan un módulo o algo así que se llama PHPSuexec, entiendo el texto pero mis conocimientos de PHP y administración de sitios son limitados, así que puedo estar malinterpretando, resulta que este PHPSuexec lo que hace es que permite que PHP no use un usuario genérico para las acciones que desarrolla desde Apache sino que se hacen con el nombre del usuario, lo cual me imagino puede tener enormes ventajas a la hora de manejar carpetas como /CACHE (ahora /tmp/cache) y las demás que uno antes tenía que dejar 777 se me ocurre que ese puede ser el problema.

Mi pregunta sería si debo investigar más por ese lado e intentar contactar el proveedor (que casi nunca responde) o sencillamente aplico la solución que se propone en http://www.spip-es.net/Problema-de-SPIP-1-9-con-PHP-4-4-6 la verdad es que no me siento muy cómodo parchando el PHP me preocupa "meter la pata" y dañarlo más

Gracias de nuevo,

Germán

German Bustos escribió:

Hola,

He tenido un fin de semana preocupante porque varios de mis sitios se cayeron sin explicación alguna, el navegador muestra un mensaje de error
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
como se ve en http://www.pazfuerzayalegria.net/

Al parecer es un problema de configuración del servidor, por tanto no parece tener nada que ver con SPIP. No les escribiría si no fuera porque me pasó exactamente lo mismo en dos servidores, de diferentes proveedores y además (que es lo que llama la atención) si no notara que otras aplicaciones LAMP siguen funcionando perfectamente (por ejemplo: http://galeria.pazfuerzayalegria.net/main.php

No he empezado a recuperar los sitios de este servidor (son tres) porque tengo urgencia de entregar el otro al cliente. Para poder recuperar en el otro servidor, lo primero que probé fue borrar la caché manualmente (en la carpeta /tmp/cache es un SPIP 1.9.2) no funcionó, también borre los datos de /tmp/sessions y /tmp/visites nada.

Para descartar que no fuera un problema de configuración del PHP instalé un Drupal usando Fantastico desde el panel de control, todo perfecto.

Después decidí borrar el archivo /config/inc-connect.php Me alegré mucho cuando en primera plana me mostró un letrero de sitio en curso de modificación, pude reinstalarlo y ver el espacio privado (la base de datos estaba intacta), pero después cuando intenté ver el lado público no funcionó, volvió a mostrar el error y perdí el acceso al área privada. Tuve que borrarlo por completo e instalarlo de nuevo, ahora está funcionando pero gaste mucho tiempo en esa operación.

El que recuperé es un sitio nuevo, así que a pesar de todo fue relativamente sencillo. Me preocupan los que me faltan que son sitios con muchos artículos y esqueletos complejos. Datos curiosos: en ese servidor tengo instalados cuatro SPIP, se dañaron 3, el que salvó también tiene esqueletos complejos, pero dos de los que cayeron tienen apenas unos pequeños retoques al esqueleto dist. En esos tengo las dos versiones de SPIP 1.9 (no tengo a mano el dato exacto pero recuerdo que unos son más actualizados que otros). También se cayó un eGroupWare y dos instalaciones de PHPlist, sobrevivieron un Moodle, dos instalaciones de Gallery

¿Creen que los esqueletos tendrán algo que ver con el problema?
¿Alguien sabe como salir de estar sin tener que volver a montar todo el sistema?

Muchas gracias,

Germán

--

Germán Bustos
german_bustos@gmx.net
http://www.atarraya.org/german

Carlos3 · Avril 23, 2007, 6:27

A mi también me ha ocurrido pero en un spip 1.7.0, y el problema ha durado un par de minutos, y siempre ha coincidido borrando archivos de la BD

Saludos

Carlos Peña

El 23/04/2007, a las 16:08, German Bustos escribió:

Hola,

He tenido un fin de semana preocupante porque varios de mis sitios se
cayeron sin explicación alguna, el navegador muestra un mensaje de error
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
como se ve en http://www.pazfuerzayalegria.net/

Al parecer es un problema de configuración del servidor, por tanto no
parece tener nada que ver con SPIP. No les escribiría si no fuera porque
me pasó exactamente lo mismo en dos servidores, de diferentes
proveedores y además (que es lo que llama la atención) si no notara que
otras aplicaciones LAMP siguen funcionando perfectamente (por ejemplo:
http://galeria.pazfuerzayalegria.net/main.php

No he empezado a recuperar los sitios de este servidor (son tres) porque
tengo urgencia de entregar el otro al cliente. Para poder recuperar en
el otro servidor, lo primero que probé fue borrar la caché manualmente
(en la carpeta /tmp/cache es un SPIP 1.9.2) no funcionó, también borre
los datos de /tmp/sessions y /tmp/visites nada.

Para descartar que no fuera un problema de configuración del PHP instalé
un Drupal usando Fantastico desde el panel de control, todo perfecto.

Después decidí borrar el archivo /config/inc-connect.php Me alegré mucho
cuando en primera plana me mostró un letrero de sitio en curso de
modificación, pude reinstalarlo y ver el espacio privado (la base de
datos estaba intacta), pero después cuando intenté ver el lado público
no funcionó, volvió a mostrar el error y perdí el acceso al área
privada. Tuve que borrarlo por completo e instalarlo de nuevo, ahora
está funcionando pero gaste mucho tiempo en esa operación.

El que recuperé es un sitio nuevo, así que a pesar de todo fue
relativamente sencillo. Me preocupan los que me faltan que son sitios
con muchos artículos y esqueletos complejos. Datos curiosos: en ese
servidor tengo instalados cuatro SPIP, se dañaron 3, el que salvó
también tiene esqueletos complejos, pero dos de los que cayeron tienen
apenas unos pequeños retoques al esqueleto dist. En esos tengo las dos
versiones de SPIP 1.9 (no tengo a mano el dato exacto pero recuerdo que
unos son más actualizados que otros). También se cayó un eGroupWare y
dos instalaciones de PHPlist, sobrevivieron un Moodle, dos instalaciones
de Gallery

¿Creen que los esqueletos tendrán algo que ver con el problema?
¿Alguien sabe como salir de estar sin tener que volver a montar todo el
sistema?

Muchas gracias,

Germán

--

Germán Bustos
german_bustos@gmx.net
http://www.atarraya.org/german

_______________________________________________
Spip-es@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-es

kommodin · Avril 24, 2007, 6:25

Hola,

Muchas gracias por sus consejos.

Lo que me dice mi proveedor es que cambio de PHP corriente a PHPSuexec que una forma diferente de ejecutar el PH, en la que éste no actúa como módulo de Apache.

La ventaja que ofrece esta alteración es que los directorios en que SPIP tendría que escribir los hará con el nombre de usuario que uso para conectarme y no con el del usuario de Apache, lo cual implica que no es necesario dejar los permisos 777 en carpetas como CACHE, IMG o /ecrire/data. La verdad es que ni siquiera permite que se ponga a una carpeta un juego de permisos superior a 755. Este es un primer problema pero parece que no es tan grave.

El problema adicional es que no se le pueden pasar órdenes al PHP a través de archivos .htaccess porque como PHP no es ahora un módulo de Apache, este último no reconoce los comandos. Se supone que esos comandos se pasan ahora a través de un archivo llamado php.ini.

Se supone que archivo .htaccess se usa únicamente para reescribir los URL de los artículos, secciones, etc.y se usa en combinación con el archivo /ecrire/mes_options.php pero probé a no usar esos dos archivos y tampoco funcionó.

Esto no es la primera vez que ocurre, en septiembre del año pasado se publicó este mensaje:

que tuvo dos respuestas.

Pablo, no sé como lo solucionaste entonces, pero sobre todo no sé si tenías instalado mes_options y la reescritura de URLs

Muchas gracias de nuevo,

Germán

Joan Carles Martorell escribió:

Hola,

A mí me pasó lo mismo hace tres semanas y el problema fue que los del hosting habían actualizado su PHP de la versión 4.4.4 a la 4.4.6. Y el SPIP no está preparado para ello. Jaume Sala (también miembro de esta lista) encontró la solución en:

http://www.spip-es.net/Problema-de-SPIP-1-9-con-PHP-4-4-6

También puede que tenga algo que ver con el .htaccess, prueba de desactivarlo a ver si resucita.

JC

----- Original Message ----- From: "German Bustos" <german_bustos@gmx.net>
To: "Lista SPIP" <spip-es@rezo.net>
Sent: Monday, April 23, 2007 4:08 PM
Subject: [Spip-es] Se caen los sitios

Hola,

He tenido un fin de semana preocupante porque varios de mis sitios se
cayeron sin explicación alguna, el navegador muestra un mensaje de error
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
como se ve en http://www.pazfuerzayalegria.net/

Al parecer es un problema de configuración del servidor, por tanto no
parece tener nada que ver con SPIP. No les escribiría si no fuera porque
me pasó exactamente lo mismo en dos servidores, de diferentes
proveedores y además (que es lo que llama la atención) si no notara que
otras aplicaciones LAMP siguen funcionando perfectamente (por ejemplo:
http://galeria.pazfuerzayalegria.net/main.php

No he empezado a recuperar los sitios de este servidor (son tres) porque
tengo urgencia de entregar el otro al cliente. Para poder recuperar en
el otro servidor, lo primero que probé fue borrar la caché manualmente
(en la carpeta /tmp/cache es un SPIP 1.9.2) no funcionó, también borre
los datos de /tmp/sessions y /tmp/visites nada.

Para descartar que no fuera un problema de configuración del PHP instalé
un Drupal usando Fantastico desde el panel de control, todo perfecto.

Después decidí borrar el archivo /config/inc-connect.php Me alegré mucho
cuando en primera plana me mostró un letrero de sitio en curso de
modificación, pude reinstalarlo y ver el espacio privado (la base de
datos estaba intacta), pero después cuando intenté ver el lado público
no funcionó, volvió a mostrar el error y perdí el acceso al área
privada. Tuve que borrarlo por completo e instalarlo de nuevo, ahora
está funcionando pero gaste mucho tiempo en esa operación.

El que recuperé es un sitio nuevo, así que a pesar de todo fue
relativamente sencillo. Me preocupan los que me faltan que son sitios
con muchos artículos y esqueletos complejos. Datos curiosos: en ese
servidor tengo instalados cuatro SPIP, se dañaron 3, el que salvó
también tiene esqueletos complejos, pero dos de los que cayeron tienen
apenas unos pequeños retoques al esqueleto dist. En esos tengo las dos
versiones de SPIP 1.9 (no tengo a mano el dato exacto pero recuerdo que
unos son más actualizados que otros). También se cayó un eGroupWare y
dos instalaciones de PHPlist, sobrevivieron un Moodle, dos instalaciones
de Gallery

¿Creen que los esqueletos tendrán algo que ver con el problema?
¿Alguien sabe como salir de estar sin tener que volver a montar todo el
sistema?

Muchas gracias,

Germán

--

Germán Bustos
german_bustos@gmx.net
http://www.atarraya.org/german

Fernando_Toledo · Avril 24, 2007, 11:50

El Lunes, 23 de Abril de 2007 13:17, German Bustos escribió:

Gracias por sus respuestas,

Estoy intentando que el proveedor me de más información, por ahora
encontré que están actualizando PHP y usan un módulo o algo así que se
llama PHPSuexec, entiendo el texto pero mis conocimientos de PHP y
administración de sitios son limitados, así que puedo estar
malinterpretando, resulta que este PHPSuexec lo que hace es que permite
que PHP no use un usuario genérico para las acciones que desarrolla
desde Apache sino que se hacen con el nombre del usuario, lo cual me
imagino puede tener enormes ventajas a la hora de manejar carpetas como
/CACHE (ahora /tmp/cache) y las demás que uno antes tenía que dejar 777
se me ocurre que ese puede ser el problema.

Mi pregunta sería si debo investigar más por ese lado e intentar
contactar el proveedor (que casi nunca responde) o sencillamente aplico
la solución que se propone en
http://www.spip-es.net/Problema-de-SPIP-1-9-con-PHP-4-4-6 la verdad es
que no me siento muy cómodo parchando el PHP me preocupa "meter la pata"
y dañarlo más

Gracias de nuevo,

buenas yo uso suphp tambien (por seguridad a los sitios que damos hosting)
si el problema es por ese cambio, solo tendrias que revisar que tu usuario
tenga permiso a todos tus archivos desde una consola seria hacer:
chown -R pepito:pepito /home/pepito/public_html (o el directorio en custion)
--
Dock Sud BBS

telnet://bbs.docksud.com.ar

Fernando_Toledo · Avril 25, 2007, 12:01

El Martes, 24 de Abril de 2007 03:25, German Bustos escribió:

Hola,

Muchas gracias por sus consejos.

Lo que me dice mi proveedor es que cambio de PHP corriente a PHPSuexec
que una forma diferente de ejecutar el PH, en la que éste no actúa como
módulo de Apache.

La ventaja que ofrece esta alteración es que los directorios en que SPIP
tendría que escribir los hará con el nombre de usuario que uso para
conectarme y no con el del usuario de Apache, lo cual implica que no es
necesario dejar los permisos 777 en carpetas como CACHE, IMG o
/ecrire/data. La verdad es que ni siquiera permite que se ponga a una
carpeta un juego de permisos superior a 755. Este es un primer problema
pero parece que no es tan grave.

no seria un problema ya que estarías dando permisos innecesarios
ejempo: como el script web siempre corre como tu usuario, no es necesario
darle permisos a otros para que lo escriban ni lo ejecuten, quizas si, para
que los lean como mucho.

El problema adicional es que no se le pueden pasar órdenes al PHP a
través de archivos .htaccess porque como PHP no es ahora un módulo de
Apache, este último no reconoce los comandos. Se supone que esos
comandos se pasan ahora a través de un archivo llamado php.ini.

lamentablmente el suphp funciona diferente, lo que tienen que hacer es que
para tu virtualhost , puedan usar la directiva suPHP_ConfigPath asi apuntar a
un php.ini personalizado

Se supone que archivo .htaccess se usa únicamente para reescribir los
URL de los artículos, secciones, etc.y se usa en combinación con el
archivo /ecrire/mes_options.php pero probé a no usar esos dos archivos y
tampoco funcionó.

eso tiene que ver con el mod_rewirte y no deberia interferir con suphp

mas info http://www.suphp.org/
realmente para los que damos hosting y para lo usuario suphp es mejor que usar
solo modphp o php como cgi porque dar cierta seguridad y separacion entre los
diferentes virtualhosts

Esto no es la primera vez que ocurre, en septiembre del año pasado se
publicó este mensaje:
Discuter chez rezo.net
f94f1pf2af659371a9235@mail.gmail.com%3e que tuvo dos respuestas.

Pablo, no sé como lo solucionaste entonces, pero sobre todo no sé si
tenías instalado mes_options y la reescritura de URLs

Muchas gracias de nuevo,

Germán

Joan Carles Martorell escribió:
> Hola,
>
> A mí me pasó lo mismo hace tres semanas y el problema fue que los del
> hosting habían actualizado su PHP de la versión 4.4.4 a la 4.4.6. Y el
> SPIP no está preparado para ello. Jaume Sala (también miembro de esta
> lista) encontró la solución en:
>
> http://www.spip-es.net/Problema-de-SPIP-1-9-con-PHP-4-4-6
>
> También puede que tenga algo que ver con el .htaccess, prueba de
> desactivarlo a ver si resucita.
>
> JC
>
>
>
>
> ----- Original Message ----- From: "German Bustos"
> <german_bustos@gmx.net>
> To: "Lista SPIP" <spip-es@rezo.net>
> Sent: Monday, April 23, 2007 4:08 PM
> Subject: [Spip-es] Se caen los sitios
>
>
> Hola,
>
> He tenido un fin de semana preocupante porque varios de mis sitios se
> cayeron sin explicación alguna, el navegador muestra un mensaje de error
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
> como se ve en http://www.pazfuerzayalegria.net/
>
> Al parecer es un problema de configuración del servidor, por tanto no
> parece tener nada que ver con SPIP. No les escribiría si no fuera porque
> me pasó exactamente lo mismo en dos servidores, de diferentes
> proveedores y además (que es lo que llama la atención) si no notara que
> otras aplicaciones LAMP siguen funcionando perfectamente (por ejemplo:
> http://galeria.pazfuerzayalegria.net/main.php
>
> No he empezado a recuperar los sitios de este servidor (son tres) porque
> tengo urgencia de entregar el otro al cliente. Para poder recuperar en
> el otro servidor, lo primero que probé fue borrar la caché manualmente
> (en la carpeta /tmp/cache es un SPIP 1.9.2) no funcionó, también borre
> los datos de /tmp/sessions y /tmp/visites nada.
>
> Para descartar que no fuera un problema de configuración del PHP instalé
> un Drupal usando Fantastico desde el panel de control, todo perfecto.
>
> Después decidí borrar el archivo /config/inc-connect.php Me alegré mucho
> cuando en primera plana me mostró un letrero de sitio en curso de
> modificación, pude reinstalarlo y ver el espacio privado (la base de
> datos estaba intacta), pero después cuando intenté ver el lado público
> no funcionó, volvió a mostrar el error y perdí el acceso al área
> privada. Tuve que borrarlo por completo e instalarlo de nuevo, ahora
> está funcionando pero gaste mucho tiempo en esa operación.
>
> El que recuperé es un sitio nuevo, así que a pesar de todo fue
> relativamente sencillo. Me preocupan los que me faltan que son sitios
> con muchos artículos y esqueletos complejos. Datos curiosos: en ese
> servidor tengo instalados cuatro SPIP, se dañaron 3, el que salvó
> también tiene esqueletos complejos, pero dos de los que cayeron tienen
> apenas unos pequeños retoques al esqueleto dist. En esos tengo las dos
> versiones de SPIP 1.9 (no tengo a mano el dato exacto pero recuerdo que
> unos son más actualizados que otros). También se cayó un eGroupWare y
> dos instalaciones de PHPlist, sobrevivieron un Moodle, dos instalaciones
> de Gallery
>
> ¿Creen que los esqueletos tendrán algo que ver con el problema?
> ¿Alguien sabe como salir de estar sin tener que volver a montar todo el
> sistema?
>
> Muchas gracias,
>
> Germán

--
Dock Sud BBS

telnet://bbs.docksud.com.ar