jueves, 30 de junio de 2016

Squid crashed = IT en problemas

Buenos días, internautas blogueros.

Esta entrada va dedicada a quienes usan y administran Squid. Si han configurado Squid para que trabaje con Active Directory como mecanismo de autenticación para acceder a la caché, quizás les haya sucedido que el servicio se detiene de repente y se reinicia... suena un poco raro pero a mi me ocurrió. 

Lógicamente, lo primero que hice fue chequear el status de Squid, que muy simpáticamente me mostraba este mensaje: 

jun 28 08:01:14 squid.proxy.com (squid-1)[852]: Too many queued ntlmauthenticator requests

El error es claro: dado que Squid usa un programa para realizar la autenticación vía NTLM, estaba recibiendo demasiadas peticiones de autenticación que muchas quedaron encoladas y no podía responderlas. Explorando más el cache.log, encontré la solución al inconveniente:

WARNING: Consider increasing the number the number of ntlmauthenticator processes in your config file.

Así que sin más, incrementé el valor pasándolo de 20 a 50:

auth_param ntlm children 50

No soy la única que tuvo este inconveniente, está claro en el siguiente hilo de la mail list de Squid: http://marc.info/?l=squid-users&m=130930811414166&w=2

Espero que les haya sido de ayuda! Happy config!

martes, 17 de mayo de 2016

Android Studio: solucionando algunos problemitas

Buenas tardes, internautas bloggeros.

Llevo dos meses sin hacer una entrada en mi blog... no puede ser. Para cambiar esta situación pensé que sería bueno compartir cómo soluciono algunos inconvenientes que van surgiendo en las tareas que llevo adelante.

Como estoy desarrollando en Android Studio (un nuevo mundo para mi), me pasó de todo. A pesar de eso, venía bastante bien con el trabajo hasta que actualicé la IDE a la versión 2.1. Aquí les dejo uno de los errores que me saltaron y cómo los solucioné:

Error:(1, 0) Plugin with id 'com.android.application' not found

Se resuelve editando el fichero build.gradle de la raiz del proyecto con las siguientes líneas:

buildscript {
    repositories {
        jcenter()//mavenCentral()
    }

    dependencies {
       classpath 'com.android.tools.build:gradle:2.1.0'
      //  classpath 'com.android.tools.build:gradle:1.5.0'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

Eso es todo! Luego, la IDE les pedirá la resincronización, dado que se hicieron modificaciones.
Saludos... y happy config!

domingo, 20 de marzo de 2016

Squid + Active Directory

Buenas noches, internautas bloggeros.

En este post quiero comentarles sobre mi experiencia con Squid, un caché-proxy para web que soporta HTTP, HTTPS, FTP y otros protocolos que tiene ya 20 años de desarrollo. Reduce  el consumo de ancho de banda, realiza control de acceso , mejora el tiempo de respuesta cacheando y rechazando accesos frecuentes a páginas web, entre otras características.


En mi lugar de trabajo decidimos montar un servidor Squid porque realmente Fore Front no nos daba muy buenos resultados. Y esa fue mi tarea... Aparte, tenía que vincularlo con Active Directory, dado que tenemos un dominio Windows corriendo y era importantísimo tener un control de acceso por usuario.

No es mi objetivo dar detalles de la configración de Squid, sino transmitirles un poco mi experiencia con este tipo de tareas, que al principio se hizo muy cuesta arriba.

Dado que me pidieron armar el servidor "para ayer", me puse a buscar soluciones que fuesen rápidas... Entre esas soluciones se me cruzó un viejo conocido como Zentyal, también pfSense y uno nuevo por conocer: CentOS. Con el primero no tuve éxito, si bien es posible la integración del mismo con AD, pero el filtrado web por grupos de usuarios no era posible. Así que... descartado. Con pfSense me pasó algo similar... si bien he encontrado en posts de su foro algunos how-to de como consultar la base de datos de AD, había que modificar ficheros de Squid y Samba, una práctica no muy recomendada desde mi punto de vista. Con CentOS directamente no me he tomado mucho tiempo, dado que el módulo para integrarlo con AD había que pagarlo... bueno, no lo pensé mucho y no lo tomé como opción. Así es como llegué a lo que había hecho alguna vez en entornos de prueba: Debian + Squid, ni más ni menos. Era lo que conocía, lo que me había dado resultados... no podía ponerme a jugar con cosas que no conocía porque el servidor debía estar en producción lo antes posible. Afortunadamente, Squid con un fichero muy chiquitito de configuraciones de directivas ya funciona! Eso me daba tiempo para ponerlo más a punto estando ya en funcionamiento y vincularlo con el Active Directory.

Como lección me quedó que no hay que complicarse mucho cuando se tiene la solución delante de uno. Más cuando se necesita dar soluciones en un entorno donde el acceso a internet es fundamental y crítico. En particular con Squid, hay muchísima información, sobre todo en las listas de mails, donde se plantean problemas de entornos reales y contestan los mismos desarrolladores del software.

Espero que les sea útil lo que les he contado...

Saludos... y happy config!

sábado, 20 de febrero de 2016

Microsoft DNS... desde lo básico a la implementación (2)

Buenos días, internautas bloggeros.

En esta entrada quiero compartir con uds. la segunda parte del material del curso Implementing DNS in Microsoft Windows Server, que se dictó en la plataforma de cursos virtuales edX.


Tal como les contaba en la entrada anterior, el curso brindaba la parte teórica y práctica. Lo bueno es que se disponía de varias máquinas virtuales para poder realizar los ejercicios y explorar el dashboard de Microsoft Serever 2012 R2.

Aparte del material bibliográfico, les dejo las respuestas del examen final. Algunas de ellas se respondían usando la teoría, otras explorando las herramientas del servidor.
Enlace de descarga aquí: https://mega.nz/#!T48GURID

Espero que les resulte de utilidad. El material es muy bueno. En lo personal me ha despejado muchas dudas conceptuales. En cuanto a la implementación, creo que ya es cuestión de cada uno empezar a jugar y hacer pruebas.

Saludos... y happy config!

jueves, 11 de febrero de 2016

GRUB2 experience

Buenos días, internautas bloggeros.

Cuando decidí reactivar mi blog fue con la idea de volcar mi experiencia, aprendizaje, lecturas de manera de armar una "vitácora", si así puede llamarse. Por eso publiqué sobre la sincronización con rsync aquel día que debía sacar datos de mi laptop para que estén mi mi desktop. En esta ocasión les contaré sobre mi experiencia con GRUB, el cargador de arranque de Linux.

Basándonos en el artículo de la Wikipedia, GNU GRUB (GNU GRand Unified Bootloader) es un gestor de arranque múltiple, desarrollado por el proyecto GNU que se usa comúnmente para iniciar uno, dos o más sistemas operativos instalados en un mismo equipo. De la wiki de Ubuntu podemos extraer el siguiente párrafo: as the computer starts, GRUB 2 either presents a menu and awaits user input or automatically transfers control to an operating system kernel. GRUB 2 is a descendant of GRUB (GRand Unified Bootloader). It has been completely rewritten to provide the user significantly increased flexibility and performance. GRUB 2 is Free Software. Es decir, que si tenemos Debian y Linux instalado en nuestra pc, GRUB nos permitirá elegir cuál de los dos iniciar a través de un bonito menú de elección. Esto último es una de las ventajas entre GRUB2 y GRUB (lo pueden leer en el artículo de Ubuntu).

Un problema que nos surge cuando tenemos Windows y Linux instalados es que, dependiendo si instalamos primero uno u otro, nuestro GRUB será sobreescrito o no. En mi caso, Windows fue instalado al último, por lo que perdí mi arranque del sistema y directamente booteaba con Windows10.

Para resolver este inconveniente recurrí a Boot Repair Disk, que es un live CD de Ubuntu con la heramienta boot repair precargada y que detecta automáticamente los problemas de arranque del sistema. Desafortunadamente no me dió solución, por lo que tuve que realizar todo en forma manual. Para ello, desde el mismo live CD, lo primero que hice fue fijarme qué discos tengo y cuál correspondía a la partición /boot de Linux:

 [root@lubuntu ~]# fdisk -l  
   
 Disco /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectores  
 Unidades: sectores de 1 * 512 = 512 bytes  
 Tamaño de sector (lógico/físico): 512 bytes / 4096 bytes  
 Tamaño de E/S (mínimo/óptimo): 4096 bytes / 4096 bytes  
 Tipo de etiqueta de disco: dos  
 Identificador del disco: 0xf6363166  
 Device   Boot   Start    End  Sectors  Size Id Type  
 /dev/sda1      2048   684031  681984  333M 83 Linux  
 /dev/sda2     686078 850292735 849606658 405,1G 5 Extended  
 /dev/sda3  *  850292736 851316735  1024000  500M 7 HPFS/NTFS/exFAT  
 /dev/sda4    851316736 1157492735 306176000  146G 7 HPFS/NTFS/exFAT  
 /dev/sda5     686080 166699007 166012928 79,2G 8e Linux LVM  
 /dev/sda6    166701056 850292735 683591680  326G 8e Linux LVM  
 La partición 3 no empieza en el límite del sector físico.  
 Las entradas de la tabla de particiones no están en el orden del disco.  
 Disco /dev/sdb: 149,1 GiB, 160041885696 bytes, 312581808 sectores  
 Unidades: sectores de 1 * 512 = 512 bytes  
 Tamaño de sector (lógico/físico): 512 bytes / 512 bytes  
 Tamaño de E/S (mínimo/óptimo): 512 bytes / 512 bytes  
 Tipo de etiqueta de disco: dos  
 Identificador del disco: 0x4cc979ab  
 Device   Boot Start    End  Sectors  Size Id Type  
 /dev/sdb1    2048 312580095 312578048 149,1G 83 Linux  
 .  
 .  
 .  
 Device   Boot Start   End Sectors Size Id Type  
 /dev/sdc1 *   2048 30296063 30294016 14,5G b W95 FAT32  

Como puede verse, la partición de /boot de Linux es /dev/sda1. Y algo que hizo Windows al instalarse, fue marcar su partición "reservada para el sistema" con el flag de boot.

Entonces, usando gparted (viene instalado en Boot Repair Disk), cambié el flag de boot para que la tenga Linux:


Seguidamente, debí reinstalar GRUB. Para ello lo que hice fue:

1- Montar la partición de /boot de Linux

 sudo mount /dev/sda1 /mnt  

2- Instalar GRUB2

 sudo grub-install --root-directory=/mnt /dev/sda  

Bien. Pensaba que estaba todo listo, pero al reiniciar la PC me di con que efectivamente estaba instalado GRUB, pero en vez de mostrarme el menú de selección tenía la consola de GRUB :S Me dió pánico.


Pero luego me di cuenta que era sólo una consola más, con sus comandos, pero que no sabía usar. Tal como se ve en el mensaje principal, usando <Tab> se nos muestra los comandos posibles de GRUB2. Pero necesitaba ir más a fondo. Gugleando encontré este artículo, sencillo pero excelente para alguien como yo que desconocía sobre la CLI.

Entonces, qué debía hacer? Primero ver si GRUB detectaba mis discos. Eso lo hice usando el comando ls.

 grub> ls  
 (hd0) (hd0,msdos2) (hd0,msdos1)  ...........

Luego buscar el directorio /boot. Por deducción era la partición (hd0,msdos1). Pero para ser un poco más técnica, hice la búsqueda de mi kernel:

grub> search -f /vmlinuz-3.16.0-4-amd64  
 hd0,msdos1   

Bien hecho. Pero me pregunté si todavía existía mi archivo de configuración grub.cfg. Afortunadamente SI. Entonces, lo que debía hacer era que GRUB reconozca ese fichero!

 grub> search -f /boot/grub/grub.cfg  
 hd0,1   
 grub> configfile (hd0,1)/boot/grub/grub.cfg  

Y voilá! Tuve mi menú para seleccionar el SO que quisiera (Win incluido, dado que desde el live CD, cuando al hacer el grub-install, se generó el fichero con la nueva entrada). Pero para que todos estos cambios fueran permanentes, una vez dentro de Debian, accedí a la consola e instalé GRUB:

 # update-grub  
 .....  
 done  
 # grub-install /dev/sda  
 Installing for i386-pc platform.  
 Installation finished. No error reported.  

El primero comando creo que no es necesario, pero por las dudas lo ejecuté. Una duda que me surgió sobre el binario update-grub fue qué diferencia hay entre ese y update-grub2. Bueno, lo pueden leer la respuesta acá, pero resumiendo ambos son lo mismo, de hecho update-grub2 es un enlace simbólico a update-grub.

 [verovan@phoenix ~]$ ls -l /usr/sbin/update-grub2  
 lrwxrwxrwx 1 root root 11 dic 14 14:38 /usr/sbin/update-grub2 -> update-grub  

Y así recuperé de manera definitiva el menú :D

Espero que les haya resultado útil algo de lo que les conté, siempre hay alguien que tiene el mismo inconveniente que uno. Por ello les comparto la solución que le di a este problemilla.

Saludos... y happy config!

jueves, 4 de febrero de 2016

Recomendado: libro sobre bases de datos MongoDB

Buenas noches, internautas bloggeros.

En este post quiero recomendarles un excelente libro sobre uno de los motores de bases de datos NoSQL más populares: MongoDB


Tal como la define Wikipedia, MongoDB es un sistema de base de datos NoSQL orientado a documentos, desarrollado bajo el concepto de código abierto. MongoDB forma parte de la nueva familia de sistemas de base de datos NoSQL. En vez de guardar los datos en tablas como se hace en las base de datos relacionales, MongoDB guarda estructuras de datos en documentos tipo JSON con un esquema dinámico (MongoDB llama ese formato BSON), haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y rápida. Es fácil de usar, escalable, soporta indexado, entre muchas ventajas que la hacen enormemente potente.

Mi incursión con este motor de DB fue por curiosidad. En la facultad (y en la gran mayoría) nos enseñan bases de datos relacionales, aprendemos a manejar MySQL, Oracle y todos los frameworks de desarrollo trabajan con ellas. Así que para aprender algo nuevo me suscribí al curso que dicta la MongoDB University (se los recomiendo), primero al de administrador Mongo que aprobé con una nota alta :D Actualmente estoy en la quinta semana del curso orientado a desarrolladores, y dado que me gusta el lenguaje Python, la combinación de estas dos tecnologías para mi es perfecta *.*

Para hacer algunas tareas del curso de MongoDB Admin recurrí al excelente libro MongoDB: The Definitive Guide, que fue escrito por Kristina Chodorow, quien trabajó estuvo a cargo de parte del desarrollo de replica sets de Mongo y también escribió drivers para PHP y Perl.


Cubre los conocimientos que son imprescindindibles para el manejo de MongoDB. Va desde lo más básico, como qué es un documento en Mongo, hasta la creación de replica sets y configuración del sharding. Pueden consultar aquí el índice.

Espero que les haya gustado la recomendación!

Saludos.. y happy config!

jueves, 28 de enero de 2016

Herramientas de monitoreo y análisis

Buenos días, internautas bloggeros.

En este nuevo post quiero comentarles sobre algunas herramientas para monitorear servidores (o nuestras propias pc) y algunos servicios. En particular, se trata de tener registro sobre el estado de los recursos del servidor y analizar los archivos de logs de Squid3.

Después de probar distintas herramientas, encontré algunas que me parecieron fantásticas. Es el caso de Monitorix, Lightsquid y MRTG.

Monitorix

Es un sistema de monitoreo integral, de código abierto, libre y ligero. Para poder recoger información de los distintos recursos de la máquina en cuestión, usa un demonio escrito en Perl que se ejecuta como cualquier otro servicio y un script que contiene un servidor HTTP propio, por lo que no hace falta tener Apache configurado para poder visualizar las gráficas y estadísticas a través de la web.

Puede realizar muchos gráficos, tal como se muestra en esta lista que está en su web oficial. Realiza gráficos y genera los reportes diarios, mensuales y anuales.

Monitoreo de los filesystem
Por defecto correo en el puerto 8080, es posible cambiarlo. También añadirle seguridad a través del fichero .htpasswd (igual que Apache). La configuración es muy sencilla mediante el fichero /etc/monitorix/monitorix.conf

Lightsquid

Al principio elegí SARG, ya saben, para saber por dónde navegan los clientes que se conectan al servidor proxy Squid3. Sin embargo había algo que no me convencía... Por suerte encontré Lightsquid, que está escrito en Perl y que me brinda información más detallada.

Para generar los reportes se cronea un script en Perl para que cada 20 minutos (o menos, pero no menos de diez), parsee el archivo access.log, que es el log donde Squid registra todo. Lo que más me gusta es que se puede ver a qué paǵinas web accedieron los clientes por intervalo de hora.

Reportes por día

Reporte por usuario
Para usar esta herramienta es necesario tener un Apache (u otro web server), el mod_cgi habilitado y el paquete libapache2-mod-perl2.

También genera reportes diarios, mensuales y anuales. Y en el caso de tener integrado el Squid con un LDAP, podemos realizar los reportes por usuario y no por IP, que es la configuración por defecto, sin necesidad de conectarnos desde Lightsquid al servidor de directorio (SARG trabaja de esa manera).

MRTG

También les presento otra herramienta, similar a Monitorix, pero que también puede trabajar con agentes SNMP para controlar otros servidores, routers, switches, etc. En mi caso no usé agentes SNMP, por lo que fue más sencillo aún.

Es súper fácil de configurar en Debian (se instala a través de repositorio). También se ejcuta como proceso demonio.

Estadísticas de las interfaces de red
Les recomiendo probarlas, sacarles el jugo, para tener todo bajo control y registrado ;)

Saludos... y happy config!