Archivo de la etiqueta: solución

Solucionar error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Fork me git - server certificate verification failed
Fork me git – server certificate verification failed

Este error SSL al clonar repositorio GIT suele aparecer en algunos repositorios. En mi caso particular apareció este error (server certificate verification failed) al clonar el repositorio de ffmpeg descrito en su propia página:

$ git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg

Que produce el error:

fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Esto se debe a que GIT esta intentando validar el certificado SSL de dicho repositorio y rechaza el certificado puesto que tiene algún problema (por ejemplo puede estar autofirmado o no ser válido).

Error: server certificate verification failed

Si quieres obtener más información sobre el problema, puedes mostrar más información de depuración con:

GIT_CURL_VERBOSE=1

En mi ejemplo sería:

$ GIT_CURL_VERBOSE=1 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
Clonar en «ffmpeg»...
* Couldn't find host git.ffmpeg.org in the .netrc file; using defaults
* Trying 79.124.17.100...
* TCP_NODELAY set
* Connected to git.ffmpeg.org (79.124.17.100) port 443 (#0)
* found 168 certificates in /etc/ssl/certs/ca-certificates.crt
* found 684 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Curl_http_done: called premature == 1
* Closing connection 0
fatal: unable to access 'https://git.ffmpeg.org/ffmpeg.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

Posibles soluciones

Existe una manera rápida y sucia de solucionar el problema que es ignorar el paso de verificar el certificado (ojo, esto implicaría que realmente confías en el sitio que estas ignorando y que si alguien ha reemplazado su certificado de forma maligna, tu asumirías las consecuencias), para ignorar la verificación en GIT:

$git config --global http.sslverify false

O bien puedes usar la variable de entorno:

$ export GIT_SSL_NO_VERIFY=1

 



Otra posible solución, es obtener el certificado autofirmado (archivo .crt) y añadirlo a la lista de los que tiene tu propio ordenador. Para ello, con el anterior comando hemos visto que el host al que debemos solicitarlo (en mi caso) es git.ffmpeg.org, luego sería el siguiente comando:

$ echo -n | openssl s_client -showcerts -connect git.ffmpeg.org:443 2>/dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'

Esto devuelve un texto, que el el certificado y que debemos añadir a nuestro listado de certificados, normalmente en la ubicación/etc/ssl/certs/ca-certificates.crt:

$ sudo nano /etc/ssl/certs/ca-certificates.crt 

Posteriormente, si es el correcto, actualizariamos con el comando:

$ sudo update-ca-certificates

Y debería mostrar que se ha añadido uno nuevo. Con ello debería permitir clonar el repositorio que produce el fallo de verificación SSL (server certificate verification failed).

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.