De siempre, me ha parecido que los autenticadores de squid son unas canchanfletas. Realmente antes me parecían otra cosa, porque la palabra “canchanfleta” no existía, pero nunca me simpatizaron mucho los autenticadores.

El hecho de que para administrar los usuarios se necesite una aplicación aparte y por lo general bien estrafalaria; es por si solo una verdadera jodienda.

El despliegue aquí en el Calixto fue prácticamente una locura. Todo a la carrera. A pesar de eso, escribí un autenticador de lo mas chulo. Al enviarle como argumento un usuario, generaba una contraseña firme y creaba un fichero bajo el directorio “/etc/squid/digest/”. El nombre de dicho fichero era el nombre de usuario y el contenido: un digest irreversible (el password).

Problema 1:

La necesidad de crear usuarios y cambiar contraseñas, pujaba la necesidad de una mecanismo más óptimo. El problema era correr ruby on rails en el server para manejar los usuarios; matar moscas a cañonazos. El rails podía crear los ficheros en mi máquina y luego cotejarlo con el servidor manualmente con “scp”, lo cual seguía siendo un fastidio. Además NO SE POR QUE, después de crear un usuario, había que reiniciar el servidor, muy a pesar de que el directorio se releía cada vez que se pedía un usaurio.

Sumado a eso, la evidente aparición de un presunto servidor de correo y la inspiración que resulta el esquema de infomed; me dejaron caer una vieja escupía en la frente; yo que era tan renuente a SQL.

Bueno, todos los usuarios pa una base de datos y problema resuelto.

Además, tengo planificado más de un servicio, así que alé por el típico esquema de una cuenta para todos los servicios.

1

SELECT password FROM users WHERE username="fulanito"

La cantidad de código del autenticador se redujo considerablemente y con ello el margen de error. La cuestión quedó sencilla: Una consulta SQL que determina si el usuario está en la base de datos y si tiene permisos de navegación. En futuro si se requiere un sistema de quotas, saldrá por ahí también.

Problema 2:

Pero entonces surgió un nuevo problema. Cuba, tierra de salvajes apagones y feroces mosquitos. La luz falla y la máquina del informático se cae. Cuando el autenticador comete algún error, squid dice que el autenticador está fallando y lo deja de pinchar. Aún si arrancase la base de datos, squid no vuelve a echar a andar el autenticador.

Entonces volvemos a lo mismo: -lazarito! no hay internet??! Junto a un nagios histérico que manda correos a diestra y siniestra. PÁFATA! De vuelta al subdesarrollo, ssh pal servidor y “squid -k reconfigure”

Solución:

El autenticador debe seguir en pie, aún cuando la base de datos no sea accesible.

La única forma de lograr esto de forma transparente hacia squid; es verificar si la conexión a la base de datos está operacional y denegar todas las autenticaciones si esta no lo estuviere.

Implementación:

Pero un autenticador de squid, es un ciclo infinito que lee stdin y habla por stdout; cargar una subrutina de rescate en cada vuelta, sería caerle a puñaladas a la memoria RAM.

Solución: En cada vuelta, se compruebe si la base de datos está en linea. En caso de no estarlo, se llama una función que establece la conexión. Este es un iterador que intentará establecer la conexión hasta que lo logre. Mientras tanto toda la autenticación en el proxy será “usuario no válido”.

1
2
3
4
5
6
7
8
9
10
11

if my
   @auth=false
else
   begin
      my = Mysql.new('10.1.1.14', 'usuario', 'password', 'basededatos') rescue false
   rescue
      STDERR << "ERR Fallo la conexión al servidor SQL #{$!}\n"
      STDERR.flush
      next
   end
end # if sql

El iterador principal sigue viendo la variable que hace como semáforo (“my” en este caso) en false y no se toma la molestia de encuestar una base de datos que ya sabe; está off-line. La variable “my” será false mientras no se redeclare con la conexión de Mysql.new. No confundir con @auth que en este caso es el valor por definicion de la autenticacion. Osea, no se autenticó.

La variable my será true cuando la función logre establecer la conexión con la base de datos.

De está forma, falla de manera silente, segura y controlada.