htaccess no funciona en Apache

Estaba agregando una contraseña a un archivo desde el archivo de configuración .htaccess de Apache2, pero resulta que no me respeta los parametros que pongo., bueno, la solución a todo esto es modificar el archivo que esta dentro de la carpeta /etc/apache2/sites-enabled/000-default (puede variar dependiendo de la configuración de tu compu).

Buscamos la linea donde dice ”AllowOverride” y en lugar que diga None , le ponemos All , así ya deberia de funcionar el .htaccess

Aquí les pongo el ejemplo de mi htaccess en donde pido la contraseña cuando se ve un archivo.

AuthUserFile /var/www/.htpasswd
AuthType Basic
AuthName “Dame la clave”


Require valid-user

Y listo!! :) , para crear el archivo de password se pone este comando cuando es la primera vez:

htpasswd -c .htpasswd nombre_usuario

Y este para agregar otro más

htpasswd .htpasswd otro_usuario

Ahora si!!!, ya están protegidas las páginas solicitadas

MySQL, Acelerar GROUP BY

En el sistema de mensajes SMS tenia una consulta SQL que tardaba demasiado, y buscando el porqué me di cuenta que el causante es la sentencia GROUP BY, ahora bien, investigando sobre esta clausula me doy cuenta que cuando uno tiene muchos registros se pone tremendamente lenta!!!, y para ello una muestra,

Tengo una tabla con 542,000 registros, y al hacer una consulta con el GROUP BY me tardaba aproximadamente 8.7seg, casi 9 segundos, y pues como solo necesitaba 1 resultado que es el que tenia en el GROUP BY, pues tenia que encontrar la forma rapida de sacar esta información, eliminando los duplicados.

Así que hice varias pruebas.

Sentencia con: GROUP BY, LIMIT tardaba 8.7 seg
Sentencia con: GROUP BY, ORDER BY, LIMIT tardaba 8.3 seg
Sentencia con: LIMIT tardaba 1.1 seg (solo que me podia repetir valores)
Sentencia con: DISTINCT, LIMIT tardaba 1.2 seg < – CON ESTA ME QUEDO!!!!

Si pueden ver, la diferencia es muy notable! entre poner un group by, sin group by y con el distinct, claro que todo depende de la informacion que saquemos, las relaciones de tablas, etc, etc…, pero bueno!!, hoy aprendi algo nuevo.

Aquí les dejo algunos tips que encontre para acelerar el GROUP BY, aunque en mi caso seguia siendo lento aplicando estas tecnicas:

* Mantener el número de fílas a devolver por la QUERY tan pequeño como sea posible
* Mantener el número de agrupaciones tan limitado como sea posible
* No agrupar columnas redundantes
* Si hay un JOIN en la misma SELECT que tiene un GROUP BY, intentar reescribir la QUERY usado una SUBQUERY en lugar de usar un JOIN. Si es posible hacer esto, el rendimiento sera major. Si se tiene que usar un JOIN, intentaremos hacer el GROUP BY por columna desde la misma tabla que la columna o columnas sobre la cual la se usa la función.
* Consideraremos el añadir un ORDER BY a la SELECT que ordena por la misma columna que el GROUP BY. Eso puede producir que el GROUP BY tenga mejor rendimiento.

Y aquí pueden ver información sobre optimización de MySQL para grandes tablas

¿Virus en el procesador? y así quieren combatir la pirateria.

Leyendo en Microsiervos me encuentro esta curiosa frase que fue la ganadora del Mes de Diciembre de la página Si eres legal eres legal

”Me lo contaron en el colegio, entre y me bajé películas, me entraron virus y me tuve que cambiar el cpu porque los virus se metieron en el procesador, no os bajéis cosas, son gente que pone cosas malas dentro de los archivos y te roban tus datos, tus fotos, y todo!!!! Se legal FACILMENTE!!! ”

Lo más raro es que quieren combatir la piratería engañando a la gente, con mentiras y más mentiras, en lugar de decir la verdad sobre la piratería, y el problema no es lo que la gente les mande en su supuesto concurso, sino el que jurado que da por ganadora la frase, deberian cambiar su página por algo que diga, Para ser legal di mentiras, ahora si estoy en un error porfas desmientanme, porque hasta donde yo se, ningun virus se puede meter en el procesador, digo, podrán pasar por el procesador, pero que lo dañe???, jajajaja en fin!.., que cosas de la vida.

Y pues aquí les dejo la imagen por si llegará el ganador del mes de Enero, (que sorpresas nos esperará).


Squid, WARNING Your cache is running out of filedescriptors – Posible solución

Despues de tanto batallar con el squid y sus filedescriptors, a la mejor encontre la solución al problema.

Resulta que cuando se trababa el squid y reiniciaba, siempre aparecia que estaba matando las conexiones que decian algo asi:

2009/01/19 10:19:33| FD 24 Closing HTTP connection
2009/01/19 10:19:33| ctx: enter level 0: ‘http://10.10.8.29:8080/versioncheck.asp’
2009/01/19 10:19:33| httpProcessReplyHeader: Too large reply header
2009/01/19 10:19:33| ctx: exit level 0

La ip 10.10.8.29 es la del servidor Squid (Gateway) y en los logs aparecia como si la propia maquina del squid pedia esa página, primero pense que era un bug del ipfire aunque viendo la extesnión ASP pues nada que ver con Linux., y a veces aparecia como si otra maquina solicita esa página y despues el Squid sigue pidiendola y pues al rastrear la IP inicial me doy cuenta que el programa LogMe In usa una peticion similar: http://homesite/versioncheck.asp

El chiste es que desinstale el LogMeIn y esperemos que ya no chafie otra vez!!! :)

No reconoce la codificación UTF-8

Por alguna extraña razón los navegadores no reconocen el juego de caracteres UTF-8 de algunas páginas web y simplemente veia caracteres raros en las ñ, acentos.

Se supone que la solución más simple es agregando en el header del documento HTML el tipo de Contenido

Pero nada de nada!!, ni con esa etiqueta funcionaba bien la codificación del HTML, así que solamente nos queda la solución drastica!!, desde Apache especificar el tipo de codificación, por eso debemos de editar el archivo /etc/apache2/apache2.conf (si usamos la ultima versión de apache, sino es /etc/apache/apache.conf) buscamos la linea donde diga AddDefaultCharset y ponemos esto:

AddDefaultCharset UTF-8

Reiniciamos el servidor Apache y listo!!!, ya debe de funciona bien ,pero eso si!!, siempre debemos de usar UTF-8 en lugar del ISO-8859-1

Problemas con Squid, WARNING! Your cache is running out of filedescriptors

Desde hace meses he tenido el siguiente problema con Squid, el cual se ejecuta en la versión de IPFire 2.3 con kernel ipfire 2.6.25.19-ipfire, (como referencia, nada más).

Como comentario offtopic, si no saben que es IPFire y de casualidad han escuchado sobre IPCop ó SmoothWall, haa pues es algo como esos!!, osease un Todo en Uno para funciones de Firewall, Proxy-Cache, QoS, etc, etc…

Bueno, siguiendo con el tema de los filedscriptors, resulta que a veces, el acceso a páginas web se alenta, se alenta y pues ya no deja hacer nada!, y viendo los logs del cache.log me doy cuenta que tengo muchos mensajes que dicen:

2009/01/14 03:27:52| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:28:08| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:28:24| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:28:40| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:28:56| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:29:12| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:29:28| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:29:44| WARNING! Your cache is running out of filedescriptors
2009/01/14 03:30:00| WARNING! Your cache is running out of filedescriptors

Y así sigue indefinidamente, de hecho cada vez que alguien quiere ver alguna página pues se marca eso en el log!..,
Ahora, buscando la solución he leido que se aumente el tamaño de los descriptores de archivos:

En el squid.conf y aumenta esta linea:

max_filedesc 4096

Grabar y después ejecuta esto

ulimit -HSn 4096

Y despues ver en el archivo /var/log/squid/cache.log si tenemos el cambio realizado:

2009/01/14 10:03:31| With 4096 file descriptors available

Pero aun así no funciona, digamos que solo aargamos la agonía del squid jeje., tambien lei que el tiempo de vida de cada usuario debe de bajar ya que por default es de 1 día.

Otra vez en el squid.conf

client_lifetime 60 minutes

Ya que segun al documentación oficial de squid nos dice:

The maximum amount of time that a client (browser) is allowed to remain connected to the cache process. This protects the Cache from having a lot of sockets (and hence file descriptors) tied up in a CLOSE_WAIT state from remote clients that go away without properly shutting down (either because of a network failure or because of a poor client implementation). The default is one day, 1440 minutes

En fin!!, esperemos que funcione!! :) (si a alguien le paso esto, no sea gacho y pase la solución)

Tetris Analógico

Si alguien se pregunto alguna vez, como jugaban tetris antes de que existiera una computadora, CODECO (codificado-decodificado-codificado) nos muestra una ingeniosa solución



Tetris analógico // Analogical Tetris from Esferobite-DSK on Vimeo.

Si quieren ver más vídeos o información de proyectos un poco fuera de serie como un antivirus para humanos?, de Respaldo de Bin2PDF y muchas otras cosas interesantes de la era Analógica, visiten el blog de CODECO

Hasta siempre CHIA, te vamos a extrañar muchisimo

Con la mala noticia que mi perrita la Xoloizcuintle “CHIA” fue atropellada en este periodo vacacional y pues aquí tengo el ultimo video de ella!, la verdad siento tristesa por lo sucedido, pero lo bueno es que nos dio casi 1 año de muchísima alegría!, ahora valoro y entiendo a las personas que lloraban por la muerte de su mascota, se siente muy feo.

Vamos Chia!!, ahora si podrás jugar con tu pelota por toda la eternidad aunque lo malo es que ya no te la voy a poder lanzar!! :’(

WTF – Llamadas Locales, Nacionales, Internacionales y MUNDIALES?????

En Melaque, Jalisco, definieron un nuevo termino: Internacional y Mundial, supongo que el Internacional son llamadas a Estados Unidos y el Mundial a Europa??, America Central???

De hecho, en la tienda de enfrente también tienen el mismo servicio de llamadas Internacionales y Mundiales.


Foto1: Servicio de Fax y Larga Distancia: Local, Nacional, Internacional y Mundial