Archivo de la etiqueta: config

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

Distutils2 el posible futuro del empaquetado de aplicaciones en Python

Distutils (Python Distribution Utilities) es un módulo estándar de la biblioteca de python con el propósito de distribuir aplicaciones Python de forma sencilla. Es el módulo estándar para empaquetado de aplicaciones en Python.

Si has utilizado distutils en pequeños proyectos puede que haya sido suficiente para tus necesidades. Sin embargo, a medida que es necesario personalizar con más detalles la instalación o realizar funciones avanzadas, distutils resulta ser un módulo carente de algunas funcionalidades y con muchos pequeños detalles por mejorar. Es simple, pero limitado y no extensible de forma trivial.

En mi opinión, hay dos principales problemas en la forma en la que se distribuye aplicaciones y módulos python:

  • 1) Existen muchas formas de realizar la instalación de una distribución de paquetes Python y crea un estado de interoperabilidad difícil.
  • 2) No existe una API para conseguir información de las distribuciones de paquetes instaladas.

Alternativas

Están disponibles otras alternativas como Setuptools. Este proyecto nació para rellenar pequeñas funcionalidades olvidadas en distutils y explorar nuevas direcciones. Para algunas subcomunidades Setuptools es un estándar de facto. Pero actualmente su desarrollo no esta siendo mantenido (por inactividad en 2 años) y su uso esta en decadencia desde que no tiene soporte para python 3.x.

Posteriormente surgió Distribute. Es un fork como reemplazo de Setuptools iniciado por los mismos desarrolladores que sentían que el proyecto no avanzaba lo suficiente y pensaban que no era posible una evolución.

De este último grupo ha surgido una nueva biblioteca, llamada Distutils2. Iniciada desde la base de distutils y tomando las buenas ideas de Setuptools (discutidas fuertemente en PEPs como PEP 376, PEP 386), además de inspirarse en un instalador básico similar a pip.

Integración Distutils2

Distutils2 tenia como principal objetivo la integración como módulo nativo en la rama de Python 3.3 bajo el módulo packaging. Debido a problemas en su desarrollo esta semi-paralizado hasta Python 3.4 a la espera de acuerdos entre desarrolladores y fijación de objetivos aunque este cuenta con una buena cobertura de test y estabilidad.

Novedades

Compatibilidad con otros sistemas

Distutils2 Estado actual del empaquetado de aplicaciones Python
Estado actual del empaquetado de aplicaciones Python

Los módulos de Distutils2 están capacitados para funcionar con PyPI y los metadatos asociados en proyectos instalados. El objetivo a largo plazo es la coexistencia de proyectos escritos para Pip o Distribute puesto que usan los mismos estándares. Por ejemplo, esta iniciándose una remodelización de pip, llamada pip2 que debería comtemplar la coexistencia con distutils2.

Nuevos comandos de instalación

Distutils2 habilita nuevos comandos de instalación como:

  • test : un comando para ejecutar las pruebas del proyecto (idea inspirada en Setuptools).
  • upload_docs: un comando para subir la documentación a packages.python.org
  • check: previamente añadido, pero ha sido mejorado para que se realicen comprobaciones antes de liberar o subir un paquete. Comprueba los metadatos, cumplimiento de reglas reST en la descripción.
  • uninstall: es una función muy básica añadida en el módulo distutils2.util que permite desinstalar de forma sencilla la aplicación. Esta ha sido una petición muy demandada para python 3.3. Además se incluye una API para eliminar todos los archivos que no cambiaron o directorios vacíos. Por ejemplo, para listar una lista de todos los archivos posibles para desinstalar:
from distutils2.util import uninstall
uninstall('setuptools')

Grafico de dependencias

El módulo constructor de grafos de dependencias de paquetes analiza las dependencias entre varias distribuciones de paquetes y permite a través de una API de código crear un grafo representando las relaciones entre ellos. Se sirve de graphviz para realizar los gráficos desde lenguage DOT. Por ejemplo, este sería el aspecto más básico y sin personalizar de un paquete de dependencias con el nombre “bacon”.

Gráfico de dependencias generado
Gráfico de dependencias generado

Archivo de configuración

Distutils2 toma como primera opción el archivo distutils2.cfg además del setup.cfg para permitir la compatibilidad con antiguos archivos de configuración. Es posible por tanto configurar la instalación sin necesidad de setup.py y sólo usar setup.cfg. Por defecto, los archivos como README o README.txt además del setup.py no serán más incluidos en la opción de distribución de fuentes.

Generación del archivo de configuración

Editar los archivos de configuración desde cero puede resultar muy tedioso, por ello se ha ideado un script interactivo (mkcfg) que permite generar el archivo setup.cfg preguntando los datos esenciales.

Para ejecutarlo:

$ python -m distutils2.mkcfg

Hooks

Distutils2 permite ser extensible a través de comandos que se ejecutan antes y después de una opción (hooks). Los hooks son simples funciones python (u objetos invocables) que están especificados en el archivo de configuración usando los nombres completos.

Los hooks se ejecutan después de que las opciones sean leídas y antes y después del comando a ejecutar.  Un ejemplo de hook necesitaría inicialmente que el hook estuviera presente en la ruta de ejecución, es decir, en el directorio del setup.py. Se crea un archivo en python para el hook, por ejemplo myhoook.py para el comando de instalación:

def my_install_support_hook(install_cmd):
    print "Genial, acabas de instalar mi proyecto! Ahora visita mi web blablable.com para soporte."

Posteriormente se edita el archivo setup.cfg bajo la sección de comandos apropiadas para la instalación:

[install]
pre-hook.myproject = myhooks.my_install_support_hook

Nuevas keywords

En la función setup donde recibe todas las palabras claves como autor, email, version, etc se han añadido nuevas que faciliten un mayor control.

Sistema de logging mejorado

La primera versión de disutils incluye un modulo de depuración para mensajes de error e información que no utilizaba el módulo logging estándar de Python, es decir siguiendo el estilo del PEP 282. La nueva versión de distutils2 usa de forma nativa el módulo logging.

Instalación

Si te ha parecido interesante el módulo de Distutils2, probablemente estés muy interesado en probarlo e instalarlo.

Para instalarlo puedes seguir la guía de instalación o el tutorial que se ofrece desde la documentación

Para python 2.7 puedes probar a instalarlo desde pip:

$ sudo pip install distutils2

Para Python 3, necesitas instalar (en Ubuntu) pip con compatibilidad para python3 con el paquete python3-pip:

$ sudo apt-get install python3-pip

Y después instalarlo vía:

$ sudo pip install http://hg.python.org/distutils2/archive/python3.tar.bz2

Si estas interesado en ver el código, puedes clonar el repositorio Mercurial con:

$ hg clone http://hg.python.org/distutils2

Como contribuir

Los autores de Distutils2 animan a contribuir y realizar sprints para finalizar características pendientes y corregir fallos.

Fuentes

Como crear un servidor proxy con Squid en Ubuntu

Como crear un servidor proxy con Squid en Ubuntu - Squid Cache Logo
Squid Cache

Un servidor proxy tiene la misión de actuar de intermediario en el acceso de un recurso en internet. Suelen utilizarse como pasarelas que permitan acceder a páginas webs restringidas por país o dentro de una empresa, es decir, pueden trabajar como muro cortafuegos operando en la capa de red (actuando como filtro de paquetes, como es el caso de iptables) o bien desde la capa de aplicación controlando diferentes servicios.

Funciones servidor proxy

Otra de sus funciones es actuar como caché de contenido de red (principalmente para el protocolo HTTP), proporcionando mayor proximidad de los clientes a un caché de páginas y archivos de forma que estos accedan con tiempos similares a los de una red local.

En este sentido el servidor de proxy cache Squid tiene un alto rendimiento además de soportar FTP o incluso HTTP sobre IPv4 e Ipv6. Todos los objetos cacheados por Squid permanecen en RAM, incluso consultas de búsquedas DNS. Es importante recalcar que Squid administra todas las peticiones bajo un único proceso asíncrono y no bloqueante. Por otro lado se ofrece soporte SSL y listas de control de acceso.

Proceso de interacción de un servidor proxy

Durante el proceso de interacción ocurre lo siguiente:

  1. Un cliente se conecta hacia un Servidor Proxy.
  2. El cliente solicita una conexión, archivo u otro recurso disponible en un servidor distinto.
  3. El Servidor Proxy proporciona el recurso ya sea conectándose hacia el servidor especificado o sirviendo éste desde un caché.
  4. En algunos casos el Servidor Proxy puede alterar la solicitud del cliente o bien la respuesta del servidor para diversos propósitos.

Este último punto 4, es que permite realizar muchas configuraciones personalizadas a los administradores de sistemas.

Instalación de Squid

En este artículo se instalará Squid 3.1. Para instalarlo en Ubuntu o Debian based:

sudo apt-get install squid3

Después se debe editar el fichero de configuración por defecto /etc/squid3/squid.conf

Por defecto el acceso http esta negado para todas las peticiones. Por ello debes buscar y borrar en el archivo la configuración:

http_access deny all

En su lugar se puede configurar una lista de acceso basada en rangos de IP al que se quiera permitir el acceso, por ejemplo:

acl our_networks src 123.123.123.0/24 213.213.213.0/24
http_access allow our_networks

De igual forma puedes comprobar que la directiva http_port este apuntando al puerto 3128 por defecto o cambiarlo al que necesites. Debes tener en cuenta que de acuerdo a las asignaciones hechas por IANA y continuadas por la ICANN desde el 21 de marzo de 2001, son los Puertos Registrados (rango desde 1024 hasta 49151)  y los recomendados para Servidores Proxies son el 3128 y 8080 a través de TCP.

También se pueden configurar varios:

http_port 3128
http_port 8080

O incluso especificando varias IPs:

http_port 192.168.1.254:3128
http_port 192.168.1.253:8080

Una vez configurado, es necesario reiniciar squid con:

sudo service squid3 restart

También existen otras opciones como recargar la configuración:

service squid reload

Parar el servicio:

service squid stop

O iniciarlo:

service squid start

Si tienes chkconfig (Sistemas basados en RedHat como Centos) puedes activarlo automáticamente en cada inicio del sistema con:

chkconfig squid on

Para comprobar si se está ejecutando correctamente:

sudo service squid3 status

Y si esta efectivamente escuchando en el puerto configurado:

netstat -tulpn | grep 3128

Si existe algun error grave, que no permita iniciar el servicio se debe examinar el contenido del fichero /var/log/squid/squid.out

Se puede acceder a los ficheros de log mediante:

sudo cat /var/log/squid3/access.log

O bien el fichero de cache:

sudo cat /var/log/squid3/cache.log

Para conocer la ip pública del proxy puede utilizarse:

curl ifconfig.me

Modificaciones de configuración básicas

Para mostrar las cadenas de las consultas http en el log, es necesario desactivar la directiva strip_query_terms (por defecto activa) en /etc/squid3/squid.conf:

strip_query_terms off

Por otro lado el parámetro cache_mem establece la cantidad de memoria RAM dedicada para almacenar los datos mas solicitados y datos en tránsito (con mayor prioridad de almacenamiento). Los datos son normalmente almacenados en bloques de 4 Kb. El valor por defecto es de 256 MB, pero puede especificarse una cantidad mayor si es necesario. Por ejemplo puede establecerse 2 GB de memoria:

cache_mem 2048 MB

Por defecto, si algo ocurre con la caché, como por ejemplo que el proceso se termine, se enviará un mensaje de aviso a la cuenta de email del webmaster en el servidor. Para configurarla pues cambiarse la directiva cache_mgr:

cache_mgr [email protected]

Se puede especificar un lugar diferente para el registro de accesos con la directiva access_log:

access_log /var/log/squid/access.log squid

Para ver toda tu configuración squid, sin mostrar los comentarios, puedes usar:

cat /etc/squid/squid.conf | sed '/ *#/d; /^ *$/d'

O bien:

grep -v "^#" /etc/squid/squid.conf | sed -e '/^$/d'

Solución de errores

Si intentas conectar a tu servidor proxy y este no atiende tus peticiones, es posible que no hayas abierto los puertos en tu router. Se recomienda abrir el puerto TCP/UDP en el que este configurado Squid.

Fuentes y enlaces relacionados

– Sitio web Squid Cache

– Proyecto Squid en Launchpad

– Desarrollo del proyecto Squid con Bazaar

RoadMap de Squid

Manual Squid LinuxParaTodos

UnixCraft: Setup a transparent proxy with Squid in three easy steps

– Install Squid Proxy Server on CentOS / Redhat enterprise Linux 5