Hace un momento quiise entrar a este blog y me dió un problema secundario extraño como si el load del cluster fuera excesivo.

El proveedor estaba funcionando raro a principios del año pasado y se corrigió a mediados, pero los ajustes que hizo la semana pasada pueden estar pasando la factura.

Estamos en proceso de estabilización de servers con el, y espero que el próximo fin de semana se elimine el cluster lobogris, quedando solamente lobonegro.

Sin embargo, creo que de todo el cluster los dominios actuales menos este y un foro de Dark Crow no usan bases de datos, asi que no debería ser un load alto en estas circunstancias. Observaré.

El analizador de código probablemente sale al aire en versión beta hoy o mañana.

UPDATE: El proveedor dejó el server de base de datos en el otro cluster… Los sitios estáticos se cargan de volada pero no aquellos con base de datos.

Por lo que veo si quiero dedicar mas tiempo de nómina al analizador de código será via un cambio de licencia. El proyecto puede servir para el software SaaS que estamos usando, así que habrá mas respaldo usandolo como LGPL que como GPL, eso si, versión 2.

Por otra parte ayer instalé una Maquina virtual con XP para pruebas del tunneling en el windows 7. No me gustan las máquinas virtuales, pero como necesito acceso a ciertos correos de outlook express por las pruebas, no se puede hacer con windows 7. Así que en el windows xp irá outlook express.

Noté que por no estar usando lightspeed, en ocasiones algunos procesos de apache usan cada uno 6% de CPU en el servidor.

Actividades autoasignadas de hoy:
1 ) Terminar el analizador de Reporte de TD, porque la información origen viene dañada.
2 ) Instalar Tunneling.
3 ) Preferentemente avanzar en el mecanismo de parser

Ayer noté una lentitud tremenda en el server original que acabo de mover dominios. Lo primero que noté fue un problema en el tamaño del log de messages. Tenía mas de 90 mil líneas en dos dias. Al abrirlo, noté intentos de dns poisoning .

Este es el código simple que hice para verificar incidencias de dns poisoning en el log de messages bajo var/log/

Requisitos: Primero alteré el nombre de messages a messages.txt
Proceso lógico y ampliaciones para estadística en pseudocódigo
inicia bucle fin archivo
esperado=»NO»;
$cadena=lee linea;
avisa que linea estoy leyendo
si encuentra dominio sube contador uno
si «view internal: received notify for zone» {suma contador propio; esperado=»SI»;}
si «view external: query (cache)» suma contador propio
si «sending notifies»
si «host pure-ftpd:»
si «host kernel: Firewall: *TCP_IN Blocked*»»
si «internal: loaded serial»
si esperado==»NO» {contadoresperado+1; mostrar cadena}
termina bucle

El código implementado me mostró problemas de 50% de incidencias en el messages.

Cofigo PHP:

http://alfonsoorozcoaguilar.com/codigo/dnspoisoning.txt

En 1997 mas o menos, al tratar de contratar programadores para la empresa en la que estaba, noté un problema cualitativo en los programadores que llegaban a hacer examenes. Hoy, casi quince años después, tengo un problema similar con los out sourcings de clientes.

Si bien desde hace unos siete años las circunstancias del trabajo en la empresa de galletas obligaron a contratar técnicos en el interior del país para formatear pc e instalar infinitum, noto que en la actualidad el problema es peor, inclusive los pseudo técnicos tienen un nivel PESIMO de lectura de comprensión.

Por el momento, hay una implementación que no puede terminarse en 17 dias, y no por causas atribuibles a nosotros, sino que su técnico no entiende lo básico, y me da la impresión de ser out sourcing. De momento ya avisé a los socios que saben de lo técnico de la empresa por enésima vez, así que no queda mas remedio que esperar.

Aprovecharé por si es problema del Linux a cargar Una VM con Xp Sp3 absolutamente limpia, pero por mas que veo, es un error del outsourcing de a quien debo implementar.

Ya me contestço el proveedor, pero como ese dominio nunca lo había usado para servers, seva a tardar mas tiempo la propagación de los DNS y NS.

Por mientras ya puse exim en 25 y 26, compilè Curl y estoy a la mitad de la compilación de pdflib para php.

Hace un momento contraté dos servidores nuevos, uno para la pyme y otro para las AC.

Uno de los proveedores en Dallas cambió su polìtica de precios , yme convino dividir un server. Básicamente la nueva política tenìa que ver con contratar de manera obligatoria 25% mas servicios.

De todos modos es buena idea probar de una vez litespeed, creo que será bastante util.

A esperar los correos del proveedor.

El dia de hoy salió un comentario en varios lugares citando esta noticia, básicamente uno de los proveedores mas caros de servidores y hospedaje en «the cloud» tuvo una falla fatal.

http://www.webhostingtalk.com/showthread.php?t=1008324

Afortunadamente La nube no es práctica para aplicaciones de gestión que se hacen para el gobierno, por la pérdida de control de donde está la información y por la introducción de nuevos puntos de falla.

Ouch

Pasé un rato revisando los spammers que están tratando de darse de alta en rojointenso.

La mayoría de los sitios grandes que conozco como WHT tienen a una persona de tiempo completo lidiando con eso a mano. El software que hice hace poco mas de un año para eliminar automáticamente spammers por país puede ser util para otros, y ponerlo GPL puede ser util por otros motivos. Quizá en una semana empiezo a publicar fragmentos por aqui.

Como persona que administro servidores para Mis empresas , mi trabajo/cliente principal y para fines personales, he visto bastantes cosas. Sin embargo me llama la atención un problema actual en cuanto a intentos de intrusiones por fuerza bruta en varios dominios con Drupal, y después de activar watchdog he notado varios problemas en ciernes, no de los sitios sino de la tecnología presente.

 Siendo sinceros, es google el principal vistador de dominios y servidores, asi que en la practica los webmasters pagamos ancho de banda, disco y cpu, para que se lo lleven los crawlers. Varios de los dominios afectados sufren directamente de ataques de fuerza bruta sobre directorios diversos, buscando archivos correspondientes a Sharepoint y otras aplicaciones. Hay que dedicar un espacio posteriormente a analizar las implicaciones de esa tendencia de los crawlers a parasitar los pagos de servidores.