Archivo de la categoría: Cpanel

Solucionar error symbol lookup error: suhosin.so: undefined symbol: php_mb_encoding_translation en PHP 5.4 con cPanel

Suhosin logo
Suhosin logo de Hardened PHP Project

Si has actualizado a PHP 5.4 en cPanel es posible que durante la subida de archivos u otras partes de tu código PHP te encuentres el siguiente error en el error_log de Apache.

/usr/bin/php: symbol lookup error: /usr/local/lib/php/extensions/no-debug-non-zts-20100525/suhosin.so:
 undefined symbol: php_mb_encoding_translation

Este error sólo se produce si además tienes activo Suhosin. Oficialmente PHP 5.4 no tiene soporte para Suhosin, pero esta extensión es muy necesaria para el uso de servidores compartidos, debido a que ofrece bastantes características de seguridad adicionales a la instalación base de PHP.

El problema se debe a que varias funciones relacionadas con mb string no estan presentes en el código fuente de PHP (probablemente porque cPanel usa una versión propia y ligeramente modificada del código original de PHP), donde puede haber sido eliminada la función php_mb_encoding_translation

Podemos observar, que en el código fuente de la versión PHP 5.4.19 se encuentra definida la función php_mb_encoding_translation() en concreto en /ext/mbstring/mbstring.c:102. Teóricamente esta función existe en el código nativo de PHP y suhosin debería poder utilizarla, pero al ser la versión PHP personalizada de cPanel no esta presente y suhosin falla al ejecutar el código php y eso producirá un error 500 en Apache abortando la ejecución del script.

Afortunadamente, existe un parche en Github en forma de Pull Request cuyo autor es Jan Ingvoldstad, que no ha sido aún aceptada después de más de 8 meses (al momento de escribir este artículo).

Puedes aplicar directamente el parche en el código fuente de github y compilarlo. En mi caso, he creado un repositorio aparte haciendo cherry picking del parche y de otros parches adicionales que corrigen otros errores en PHP 5.4 con suhosin y aún no han sido fusionados en el proyecto original.

La forma rápida de solucionarlo sería:

1 – Clonar mi repositorio de Suhosin con los parches aplicados (cherry picking)

git clone -b master --single-branch http://github.com/shakaran/suhosin.git suhosin-shakaran

2 – Compilar e instalar suhosin desde mi rama. En una sola línea sería:

cd suhosin-shakaran; phpize; ./configure; make; make install

Pero si quieres hacer tu propio cherry picking te explico como podrías hacer lo mismo que yo:

1 – Dirígete a github, en el repositorio oficial de suhosin y haz un fork del proyecto original

2 – Añade como repositorio remoto la rama de Jan Ingvoldstad

git remote add jani-upstream git://github.com/jani/suhosin.git

3 – Baja los commits de dicha rama (solo las referencias)

git fetch jani-upstream

4 – Haz un cherry pick del commit (parche) que arregla el fallo:

git cherry-pick e8beb4f50fa997c0ea4b923677deb275cc7660e

5 – Compila con:

cd suhosin-shakaran; phpize; ./configure; make; make install

Y listo, tendrás tu propio branch con tu parche aplicado.

Apache error 500: eAccelerator: shmmax should be at least 2MB

Este molesto error aparece en algunos servidores que puedan tener instalados cPanel con eAccelerator. Puede ser que alguna actualización de cPanel cambie valores por defecto del php.ini de PHP y en mi opinión una de las posibles y frecuentes causas de este fallo.

Para solucionarlo, encuentra el php.ini de tu sistema cPanel, normalmente ubicado en /usr/local/lib/php.ini

Se trata de buscar la variableeaccelerator.shm_max” y ponerle un valor mayor o igual a 2 MB. Puedes hacer un filtrado de la cadena para asegurarte que la tienes y con que valor con:

cat /usr/local/lib/php.ini | grep eaccelerator.shm_max

Por ejemplo puede salirte algo como:

eaccelerator.shm_max="0"

Es decir, que usa 0 o el valor por defecto.

Luego si tienes dicha variable puedes cambiarlo con este comando de sed (stream editor) rápidamente:

sudo sed -i 's/eaccelerator.shm_max=\"0\"/eaccelerator.shm_max=\"2M\"/g' /usr/local/lib/php.ini

O bien editar por ejemplo con el editor nano:

nano /usr/local/lib/php.ini

Y poner:

eaccelerator.shm_max="2"

También puedes jugar con la variable eaccelerator.shm_size.

Si te sigue dando problemas eAccelerator otra solución más drástica es desactivarlo, es decir, poner un “;” delante del extension="eaccelerator.so" (puede variar la ruta).

Debes tener en cuenta que el valor por defecto del tamaño de memoria compartida para el kernel 2.6 es de 32 mb.

Puedes cambiar este tamaño al valor deseado en /proc/sys/kernel/shmmax.

Por ejemplo con:

echo VALOR > /proc/sys/kernel/shmmax

O añadir la linea kernel.shmmax=VALOR a /etc/sysctl.conf así no tendrás que establecerlo manualmente cada vez que reinicies.

Por otro lado, si estas usando un VPS, asegúrate de que la memoria compartida y los buffers para sockets en la configuración del VPS son suficientes.

Para OpenVZ o tipos similares, puede comprobarlo con:

cat /proc/user_beancounter

Para un caso normal, el fail count (failcnt) debería ser cero. Si necesitaras más, deberías preguntar a tu proveedor VPS para agrandar el límite hasta que eAccelerator no fallara.

Fuentes

Documentacion eAccelerator: shm_max

Documentacion eAccelerator: shm_size

FAQ eAccelerator

Solucionar: RuntimeWarning: Python C API version mismatch for module en CentOS 5.5 con cPanel

Si utilizas CenOS y por ejemplo has decidido hacer una actualización de tu versión de Python ya que puede que estuvieras usando la versión 2.4 o 2.6 y quieres actualizar a 2.6 o 2.7 respectivamente, puede ser que te encuentres el error siguiente al ejecutar yum:

# yum
/usr/lib/python2.6/site-packages/rpm/__init__.py:7: RuntimeWarning: Python C API version mismatch for module _rpm: This Python has API version 1013, module _rpm has version 1012.
  from _rpm import *
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:
   No module named sqlitecachec
Please install a package which provides this module, or
verify that the module is installed correctly.
It's possible that the above module doesn't match the
current version of Python, which is:
2.6.5 (r265:79063, Jun  4 2010, 21:43:07)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)]
If you cannot solve this problem yourself, please go to
the yum faq at:
  http://wiki.linux.duke.edu/YumFaq

Este error se debe, a que yum, esta buscando sus bibliotecas para ejecutarse y no las encuentra. Posiblemente por que tu versión de yum esta instalada en otra versión de python anterior y la nueva no tiene dicha versión.

Existen varias formas de solucionar esto, pero en CentOS no esta documentada y a fecha de hoy en google no puedes encontrar ninguna solución. Es más acudiendo al IRC de centos pidiendo ayuda, su respuesta liberal en ingles fue “Date una bofetada o directamente disparate en la cabeza por lo que has hecho“.

Esta respuesta me indigno mucho, sobre todo porque me pareció pésimo el soporte, que sin darme solución, encima me respondía de esa forma, aparte el problema realmente reside en que ellos no son capaces de solucionártelo y puesto que no actualizan la versión de python en años “para que sea estable“, los usuarios y sysadmin deben ingeniárselas solucionando los problemas.

Luego después de experimentar mis soluciones fueron las siguientes:

Reinstalar yum a traves de rpm: esto probablemente funcionaría, pero no, ya que se instalaría incorrectamente con la nueva versión de python y no conseguí hacer nada, quizás hice mal algún paso.

– Reinstalar el paquete yum-metadata-parser que contiene las dependencias de yum. Igualmente al reinstalarlo no tuvo efecto ya que estaría cogiendo una mezcla de paths.

– Modificar la variable de entorno PYTHONPATH. De igual forma no funciono ni poniendo versiones más antiguas.

La solución final, que aunque fue cutre, conseguí hacerlo funcionar, fue la siguiente:

Buscar el binario de yum:

# which yum

En mi caso la salida fue:

# which yum
/usr/bin/yum

Luego tras comprobar que el tipo del archivo era un script en python:

# file /usr/bin/yum
/usr/bin/yum: python script text executable

Me fije en el archivo para editarlo:

# cat /usr/bin/yum
#!/usr/bin/python
import sys
try:
 import yum
except ImportError:
 print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

 %s

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
%s

If you cannot solve this problem yourself, please go to 
the yum faq at:
 http://wiki.linux.duke.edu/YumFaq
 
""" % (sys.exc_value, sys.version)
 sys.exit(1)

sys.path.insert(0, '/usr/share/yum-cli')
try:
 import yummain
 yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
 print >> sys.stderr, "\n\nExiting on user cancel."
 sys.exit(1)

Si os fijáis, nuestro error se da en este preciso archivo, ya que falla una excepción con el ImportError. Y en la primera línea tenemos un:

#!/usr/bin/python

Basta con cambiar esa línea para decirle al script que ejecute una versión antigua de python (la que funcionaba) de nuestro sistema. Es decir, cambiar (en mi caso a python 2.4):

#!/usr/bin/python2.4

Y listo, yum funcionará sin problemas. Obviamente, con un mejor análisis de la situación, se podría hacer que yum cogiera realmente la última versión de python y sus bibliotecas (probablemente por el path), pero eso requiere de mayor trabajo y tiempo y para mí esta solución fue valida. Sin embargo, si alguien esta dispuesto a comentar una mejor solución, estaré agradecido.