Configurando Squid como proxy transparente HTTPS: Introducción

La comunidad ha esperado mucho para llegar a este punto. Los manuales sobre la configuración aún siguen siendo bastante confusos al respecto, pero al fin logré una configuración funcional a integrar en mi proyecto ya existente.

Descrito pronto, el proyecto usa a squid como proxy caché, y este, usa a squidGuard mediante  url_rewrite_program para filtrar la navegación de los usuarios mediante las listas negras de shallalist .

Esta configuración mejora el proyecto en dos cosas básicamente:

• Los usuarios no necesitan configurar proxy para navegar por HTTPS (Aunque si necesitarían instalar un certificado)
• Los usuarios podrán ver un mensaje de error cuando navegan a un sitio bloqueado que usa HTTPS, aunque parezca poca cosa, se considera en realidad un gran avance de cara a los usuarios

 En este momento, me preocupan dos cosas que también deberían preocuparle a todos los que quieran seguir esta guía:

• El rendimiento por parte de squid para servir las páginas
• ¿Tendrá algún sitio demasiados problemas para funcionar con esta configuración?

Al momento de escribir esta entrada, esta configuración no ha entrado en producción, so...

Tome en cuenta que como debo instalar en varios firewall, la idea será compilar en un equipo independiente de lo que sea el firewall. De hecho, aún cuando se compile para un sólo equipo, debería considerar trabajar de esta forma.

Voy a repetir lo que ya se ha dicho hasta el cansancio: Hay cuestiones éticas muy importantes en esta configuración. Básicamente, lo mejor es explicar al usuario lo que se esta haciendo.

Apuntes sobre el error de Squid / SquidGuard en Debian: Solucionado

La nueva versión de Debian ha salido el sábado pasado. Y me aventuré a probar que se hubiera solucionado el problema con redirector protocol que detuvo tan mal a mi proyecto de firewall.

Pues resulta que no, el problema seguía siendo tal, pero esta vez tenía un poco más de tiempo disponible que la última vez (Y un problema más serio, al estar dos lanzamientos atrasados con el sistema base).

Lo quiero resumir de esta forma: El problema no era tal.
Básicamente porque es un problema que es posible resolver con un cambio en la configuración, no se debía (No del todo, al menos) a un falta de actualización en la forma en que squidGuard entendía el redirector protocol, como yo pensé en mi primer post

El truco está en la configuración del redirector en Squid. Por defecto, yo tenía

url_rewrite_children 15 startup=0 idle=1 concurrency=3

Pero según la documentación en Squid configuration directive url_rewrite_children:

concurrency=

 The number of requests each redirector helper can handle in
 parallel. Defaults to 0 which indicates the redirector
 is a old-style single threaded redirector.

 When this directive is set to a value >= 1 then the protocol
 used to communicate with the helper is modified to include
 an ID in front of the request/response. The ID from the request
 must be echoed back with the response to that request.

 
La cuestión es que al programa configurado como redirector le debe llegar una petición por parte de squid de la siguiente forma:

"http://www.google.com.sv/ 10.168.3.5/10.168.3.5 - GET myip=10.168.3.1 myport=3128";

Pero configurado concurrency, tal como lo ha dicho la documentación, se le antepone un identificador, de modo que la consulta queda de la siguiente forma.

"0 http://www.google.com.sv/ 10.168.3.5/10.168.3.5 - GET myip=10.168.3.1 myport=3128";

Lo que pasa es que lo interpreta mal: Para el, la URL que se solicita es 0 y el identificador del cliente es la URL; de hecho, toma a http: como la dirección IP del cliente, es decir, la primera parte de ip_cliente/fqdn...

La solución es algo tan sencillo como retirar concurrency:

url_rewrite_children 15 startup=0 idle=1 concurrency=0 

Si bien squidGuard debería ser capaz de manejar este problema, pues no, no voy a reclamarle tanto a la única opción viable frente a cosas como e2guardian.
Yo mismo he intentando parchear el paquete en Debian, intentando quitar el ID de la petición antes de que squidGuard lo siguiera parseando, pero tampoco, es que aunque ha funcionado parece que todo va mal, las respuestas hacia el cliente ralentizan la navegación. Que ni siquiera revisé los log de Squid con mayor detenimiento, es que tampoco tengo todo el tiempo del mundo.

Integrando (Un poco) pyramid en Eclipse: Test Automatizados

Esto será breve. Es más bien una revisión, porque con la forma en que lo hemos configurado esto se ha hecho automáticamente, y bien.

Por otra parte, acá hay algo raro que será mejor verificar: Desde una consola de nuestro entorno virtual, hay que instalar nose, y en Fedora, al menos para mí, webtest, así, en minúsculas

virtualenv proyecto-ambiente
pip install nose
pip search webtest

Buscamos a proyecto en Project Explorer. Accedemos a propiedades con Alt + Enter o desde el menú desplegable al hacer click derecho.

Buscamos la pestaña Run/Debug Settings. Hay dos perfiles configurados. En general, el que nos importa es aquel que se llama <nombre del proyecto>_test. En nuestro caso que nuestro proyecto se llama proyecto:

Lo seleccionamos en la lista, y hacemos click en Edit y aparece un cuadro de diálogo con las configuración de dichos perfiles

En la pestaña Main, debe estar configurado de la siguiente manera. Si se configuro tal como en el post anterior, ya debería estar así

En Arguments, debe estar checado Override PyUnit preferences for this launch?, de esta forma podremos configurar Nose test runner al elegirlo desde la lista desplegable

En la pestaña Interpreter, pues si, debería configurarse python_proyecto, el intepréte personalizado que configuramos en el post anterior pero parece haber un bug en esto, aunque se elija y configure tal, no se queda configurado

Por último, la verificación es de lo más sencilla. Corremos los test que vienen por defecto en la plantilla de proyecto starter de pyramid:

Vemos que, en hacia el fondo de la aplicación, hallamos la ventana Console con el resultado de la operación:

Dos cosas por si se me olvida registrarlas después:

• Para hacer más test, lo mejor será borrar el fichero test.py y luego crear una carpeta test/. Asimismo, el nombre de cada fichero debe comenzar con test
•  

Integrando (Un poco) pyramid en Eclipse

Una vez hayamos creado un proyecto (Uno sencillo, como este), configuramos a Eclipse para trabajar de forma más o menos integrada con pyramid. No, no va estar del todo integrado, apenas lo suficiente para asegurarnos de que va a autocompletar con las librerías de pyramid y para realizar los test automatizados sin mayores inconvenientes. Es que, básicamente, esto va sobre configurar el entorno virtual que creamos para este proyecto.

Y antes de otra cosa, es necesario tener instalado PyDev para que esto funcione. Y como hay guías más especializadas allá fuera, no repetiré

Abrimos el menú para abrir proyectos en File > Open Project from File System. Aparece el siguiente cuadro de diálogo

Haciendo click en Directory, nos aparece un cuadro de dialogo del sistema para buscar el directorio donde se encuentra nuestro proyecto.
Yo escogí proyecto-ambiente/proyecto (Para coincidir con el punto donde configuro el repositorio git, gusto mío), pero habrá quién prefiera proyecto-ambiente/proyecto/proyecto, que es donde se encuentra precisamente nuestro código.

Luego, se verá de la siguiente manera una vez configurado. Haciendo click en Finish, habremos terminado de configurar nuestro proyecto.

A continuación, necesitamos que Eclipse reconozca que el proyecto es python para que active ciertas funciones.
En el Project Explorer, usualmente a la izquierda, hacemos click derecho en nuestro proyecto; en el menú desplegable que aparece nos dirigimos a PyDev > Set as PyDev Project.

También podría bastar con abrir una fichero python, pero no es que la primera sea la "forma más correcta", sino que habría que pelearse más con la configuración.

Ahora, en el anterior menú desplegable del proyecto buscamos Properties o hacemos Alt + Enter para acceder al siguiente cuadro de diálogo.

Nuestra primera pestaña a configurar será PyDev - Interpreter/Grammar

La idea es configurar en Interpreter al que se encuentra instalado en nuestro entorno virtual proyecto-ambiente, y para ellos habrá que configurarlo haciendo click en Click here to configure an interpreter not listed
Aparece la siguiente ventana

Haciendo click en New, nos aparece el siguiente Cuadro de diálogo.

En Interpreter Name, configuramos un nombre cualquiera vagamente descriptivo, tanto más si vamos a trabajar en varios proyectos a la vez. 

Para Interpreter Executable, hacemos click en Browse, y si, aparece un cuadro de diálogo de tipo fichero. Buscamos dentro de nuestro entorno virtual proyecto-ambiente el directorio de ejectubles bin/, y dentro de este, a python. El cuadro de diálogo queda de la siguiente forma:

Al hacer click en Ok, nos aparece un cuadro de diálogo Selection needed, donde se nos pide agregar las librerías que se corresponden con ese interprete

Ahora, se puede ver este nuevo intérprete configurado

En este punto, podemos configurarlo como intérprete de nuestro proyecto en la lista desplegable Interpreter.

Hacemos click en Apply para seguir configurando. O en Ok, que esto sigue en otro post.

Mi objetivo se cumple: El autocompletado se rebusca en las librerías del entorno virtual

Integrando (Un poco) pyramid en Eclipse: Creando el proyecto

Este artículo muestra la forma más sencilla de empezar un proyecto con Pyramid, ya que a diferencia de Primero pasos con Pyramid no se modifica nada en orden de iniciar un gran proyecto. Además, esta vez hice algunas capturas de pantalla y creo que esa es la principal justificación

Creamos un entorno virtual para el proyecto de nombre proyecto y entramos al directorio creado

virtualenv proyecto-ambiente
cd proyecto-ambiente

Activamos el entorno virtual. Esto lo hacemos siempre que vayamos a usarlo. Así es como usamos las librerías y ejecutables que instalemos en él y no los del sistema.

source bin/activate

En este momento, el entorno se ve más o menos de esta forma:

Instalamos pyramid

pip install pyramid

Creamos un proyecto de nombre proyecto con la plantilla starter

pcreate -s starter proyecto

El pcreate ha creado un directorio proyecto:

Instalamos los paquetes python que este proyecto en específico necesita. Se configuran en proyecto/setup.py, por ahora lo dejamos tal como se configuro por defecto

python proyecto/setup.py develop

Y nuestro proyecto se ve de esta forma

Y eso es todo.

Usando snapshot para equipos virtualizados con XEN en Debian

Pese al título, esta entrada aún necesita llevar un subtítulo: "Usando qcow en máquinas virtuales en Debian Jessie", y ya, no se necesitaría mayor introducción al respecto.

Cuando se sigue una guía de virtualización en Debian, se cae por defecto en la virtualización con XEN. No hay problema, pero parece que hasta Jessie, las herramientas para administración por defecto siguen sin manejar la cuestión de snapshot para las máquinas virtuales.

Tampoco fuí capaz de encontrar una opción en xen-create-image que permita crear las imágenes con formato qcow. Crear la imagen con qemu-img create y luego apuntarla en xen-create-image con --image-dev y --swap-dev  no funciona porque sin importar qué, xen-create-image convierte las imágenes a raw.

Con todo esto, es necesario complicar el proceso de instalación de la siguiente manera:

• Creamos la máquina virtual con un disco raw, que es el formato por defecto:

xen-create-image  --hostname=pdc.salud.gob.sv --vcpus=2 --size=20Gb --memory=896Mb --ip=10.20.20.10 --gateway=10.20.20.1 --bridge=xenbr0 --arch=amd64 --role=udev --dir=/var/lib/xen/

La instalación del sistema base empezará creando dos imágenes: disk.img y swap.img , dentro de /var/lib/xen/domains/pdc.salud.gob.sv/ en este caso según el hostname dado.

• Lo convertimos a qcow (Respecto a preallocation: Resulta que en Jessie no es posible usar full, además, no soy capaz de decir si para el caso de conversión esta opción tiene algún tipo de efecto)

qemu-img convert -O qcow2 -o preallocation=metadata /var/lib/xen/domains/pdc.salud.gob.sv/disk.img /var/lib/xen/domains/pdc.salud.gob.sv/disk.qcow2

• Ahora, modificamos el fichero que define a la máquina virtual para que apunte al nuevo disco: Por xen-create-image, el fichero había quedado de esta forma:

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/disk.img,xvda2,w',
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/swap.img,xvda1,w',
              ]

Y el gran cambio será file: por tap:qcow2: y la extensión: .img por .qcow2 en donde se apunte al disco que cambiamos

#
#  Disk device(s).
#
root        = '/dev/xvda2 ro'
disk        = [
                  'tap:qcow2:/var/lib/xen/images/domains/pdc.salud.gob.sv/disk.qcow2,xvda2,w',
                  'file:/var/lib/xen/images/domains/pdc.salud.gob.sv/swap.img,xvda1,w',
              ]

Fuentes:
Using qcow2 images in Xen 4.1 on Debian 

Actualizando owncloud 8.1.8 a 9.0.0

Aunque la relación de Owncloud con Debian no pasa por sus mejores momentos ([Pkg-owncloud-maintainers] About no more ownCloud in Debian) en realidad es posible seguir instalando al primero sobre el segundo.

Siempre es recomendable mantener un ritmo de actualizaciones sano, pero si no es así, parece que es posible actualizar gradualmente (Esto es de suma importancia) de la siguiente forma:

7.0.3-debian >> 7.0.14 >> 8.0.12 >> 8.1.7>> 8.2.4 >> 9.0.2

Según se recoge en Upgrading ownCloud on Debian Stable to official packages, Esta forma gradual de hacer las actualizaciones pueden ser molestas, pero lo contrario (7.0.14 a 8.1.7, por ejemplo) es un proceso temerario que no estará automatizado por las herramientas de owncloud.

Actualizé la instalación en producción desde el punto 8.1.7 (En este contexto, se refieren al release. Mi versión era la 8.1.8) al 8.2.4.
En esta versión hubo un molesto problema con la app Documentos, cuya solución descrita en ASSERTION FAILED: tried to unsubscribe unknown callback from event "input/compositionstart" era actualizar a 9.0.2. Comprobé que con actualizar a 9.0.0 era suficiente.

Los cambios en /etc/apt/sources.list.d/owncloud.list describen básicamente el proceso de actualización:

#deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /

# Dejaron de usar el servicio de opensuse
#deb http://download.owncloud.org/download/repositories/8.2/Debian_7.0/ /

# Esta no sirve del todo. Hay un con el repositorio según parece
#deb http://download.owncloud.org/download/repositories/stable/Debian_7.0/ /

## Esta es totalmente estable, aunque no es precisamente la última versión pero si la primera del relase 9.0.0, me pareció buena idea llegar a este punto
deb http://download.owncloud.org/download/repositories/9.0.0/Debian_7.0/ /

Por último, queda señalar que el paquete para la versión 9.0 se ha cambiado a owncloud-files, y que el paquete owncloud-deps no existe para esta versión de Debian. Cuando se instale owncloud-files, apache, amavis y php van a irse por un rato (Se supone que todos serían reemplazados por owncloud-deps). Una vez instalado se instalan todos de nuevo y todo funciona de maravilla.

aptitude install owncloud-files
Se instalarán los siguiente paquetes NUEVOS:     
  owncloud-files{b} 
0 paquetes actualizados, 1 nuevos instalados, 0 para eliminar y 0 sin actualizar.
Necesito descargar 32,7 MB de ficheros. Después de desempaquetar se usarán 93,6 MB.
No se satisfacen las dependencias de los siguientes paquetes:
 owncloud-files : Entra en conflicto: owncloud (<= 8.99.99) pero está instalado 8.2.5-1.1.
                  Entra en conflicto: owncloud-config-apache (<= 8.99.99) pero está instalado 8.2.5-1.1.
                  Entra en conflicto: owncloud-server (<= 8.99.99) pero está instalado 8.2.5-1.1.
Las acciones siguientes resolverán estas dependencias

     Eliminar los paquetes siguientes:
1)     owncloud                       
2)     owncloud-config-apache         
3)     owncloud-server                



¿Acepta esta solución? [Y/n/q/?]y
Se instalarán los siguiente paquetes NUEVOS:
  owncloud-files 
Se ELIMINARÁN los siguientes paquetes:
  apache2{u} clamav{u} clamav-base{u} clamav-freshclam{u} libclamav7{u} libllvm3.0{u} libmcrypt4{u} libpq5{u} owncloud{a} owncloud-config-apache{a} owncloud-server{a} php-xml-parser{u} php5{u} php5-curl{u} php5-intl{u} php5-mcrypt{u} php5-mysql{u} php5-pgsql{u} php5-sqlite{u} 
0 paquetes actualizados, 1 nuevos instalados, 19 para eliminar y 0 sin actualizar.
Necesito descargar 32,7 MB de ficheros. Después de desempaquetar se liberarán 17,9 MB.
¿Quiere continuar? [Y/n/?] y

Y claro, backup. Hacer el backup de un sistema de backup es un poco gracioso pero así las cosas